perm filename MONTER.NOT[COM,LSP] blob
sn#807415 filedate 1985-12-02 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00037 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00006 00002 ∂27-Sep-84 1759 SCHMIDT@SUMEX-AIM.ARPA DARPA Common Lisp Conference (long summary)
C00020 00003 ∂28-Sep-84 1448 SCHOEN@SUMEX-AIM.ARPA Re: DARPA Common Lisp Conference (long summary)
C00041 00004 ∂28-Sep-84 1546 RINDFLEISCH@SUMEX-AIM.ARPA Jay Lark: DARPA Common Lisp Conference
C00063 00005 Cannery-row Lisp
C00074 00006 ∂01-Oct-84 1856 SCHMIDT@SUMEX-AIM.ARPA Re: Cannery-row Lisp
C00094 00007 ∂01-Oct-84 2210 FAHLMAN@CMU-CS-C.ARPA Cannery Row Lisp
C00101 00008 ∂02-Oct-84 1159 SCHMIDT@SUMEX-AIM.ARPA Re: Cannery Row Lisp
C00108 00009 More Cannery-row Lisp
C00122 00010 ∂02-Oct-84 1902 FAHLMAN@CMU-CS-C.ARPA Cannery Row Lisp
C00128 00011 ∂03-Oct-84 1017 SCHMIDT@SUMEX-AIM.ARPA Re: Cannery Row Lisp
C00130 00012 ∂03-Oct-84 1026 FAHLMAN@CMU-CS-C.ARPA Cannery Row Lisp
C00132 00013 ∂03-Oct-84 1617 SCHMIDT@SUMEX-AIM.ARPA Re: Cannery Row Lisp
C00156 00014 ∂03-Oct-84 1637 FAHLMAN@CMU-CS-C.ARPA Cannery Row Lisp
C00158 00015 ∂02-Oct-84 1424 SCHMIDT@SUMEX-AIM.ARPA Re: More Cannery-row Lisp
C00161 00016 ∂02-Oct-84 2213 FAHLMAN@CMU-CS-C.ARPA World peace
C00174 00017 ∂03-Oct-84 1756 FAHLMAN@CMU-CS-C.ARPA Cannery Row Lisp
C00176 00018 ∂03-Oct-84 2114 SQUIRES@USC-ISI.ARPA Re: World peace
C00182 00019 ∂04-Oct-84 0817 FAHLMAN@CMU-CS-C.ARPA World peace
C00186 00020 ∂04-Oct-84 1911 SQUIRES@USC-ISI.ARPA Re: World peace
C00188 00021 ∂04-Oct-84 2017 FAHLMAN@CMU-CS-C.ARPA World peace
C00191 00022 ∂06-Oct-84 1931 SQUIRES@USC-ISI.ARPA Re: World peace
C00196 00023 ∂05-Oct-84 1555 GRISS%hp-hulk.csnet@csnet-relay.arpa Re: World peace
C00202 00024 ∂08-Oct-84 2148 RPG Xerox
C00205 00025 ∂08-Oct-84 1300 FAHLMAN@CMU-CS-C.ARPA World peace and Xerox
C00209 00026 ∂09-Oct-84 0739 FAHLMAN@CMU-CS-C.ARPA Xerox
C00215 00027 ∂15-Oct-84 0752 OHLANDER@USC-ISI.ARPA Re: World peace
C00223 00028 ∂15-Oct-84 1019 FAHLMAN@CMU-CS-C.ARPA World peace
C00230 00029 ∂16-Oct-84 0508 OHLANDER@USC-ISI.ARPA Re: World peace
C00233 00030 ∂16-Oct-84 0853 FAHLMAN@CMU-CS-C.ARPA World peace
C00240 00031 ∂16-Oct-84 1207 OHLANDER@USC-ISI.ARPA Re: World peace
C00242 00032 ∂16-Oct-84 1826 FAHLMAN@CMU-CS-C.ARPA World peace
C00245 00033 ∂17-Oct-84 0508 OHLANDER@USC-ISI.ARPA Re: World peace
C00247 00034 ∂17-Oct-84 0736 FAHLMAN@CMU-CS-C.ARPA World peace
C00251 00035 ∂17-Oct-84 1032 OHLANDER@USC-ISI.ARPA Re: World peace
C00252 00036 ∂01-Dec-85 1756 Moon@SCRC-STONY-BROOK.ARPA More on the CL meeting
C00256 00037 ∂02-Dec-85 0828 DLW@SCRC-STONY-BROOK.ARPA More on the CL meeting
C00261 ENDMK
C⊗;
∂27-Sep-84 1759 SCHMIDT@SUMEX-AIM.ARPA DARPA Common Lisp Conference (long summary)
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 27 Sep 84 17:59:31 PDT
Date: Thu 27 Sep 84 16:51:41-PDT
From: Christopher Schmidt <SCHMIDT@SUMEX-AIM.ARPA>
Subject: DARPA Common Lisp Conference (long summary)
To: Rindfleisch@SUMEX-AIM.ARPA, Pattermann@SUMEX-AIM.ARPA
cc: Schoen@SUMEX-AIM.ARPA, RPG@SU-AI.ARPA, Feigenbaum@SUMEX-AIM.ARPA,
Nii@SUMEX-AIM.ARPA, Brown@SUMEX-AIM.ARPA, Delagi@SUMEX-AIM.ARPA,
Yeager@SUMEX-AIM.ARPA, Croft@SUMEX-AIM.ARPA
What follows is my account and analysis of the DARPA workshop
on Common Lisp. It is not meant for general distribution. I have been
somewhat one-sided in a number of places below with the belief that where
I report things inaccurately or draw incorrect conclusions, Dick Gabriel
or Eric Schoen will volunteer a correction. I would rather that this
letter not receive a wider distribution without my being given a chance
to incorporate such corrigenda.
The attendees assembled on time and gathered in a small, well
designed, lecture hall. Representatives (if not principals) of almost
every major lisp camp were there. Most of the talking was done by
people already committed to or using common lisp. Principal speakers
were Dick Gabriel, Cdr Ronald Ohlander (DARPA), Scott Fahlman, Carl
Hewett, Dan Weinreb, Guy Steele, Steve Squires (DARPA), and Kent
Pitman. Other notable speakers were Richard Greenblatt, David Moon,
Beau Sheil, Charles Hedrick, and Martin Griss. The names of several
others who contributed to the meeting have already slipped my mind, I
am afraid.
The official agenda was changed only slightly from that given
in the introductory letter. Cdr Ohlander (who conducted most of the
meeting) chose not to break up into subgroups, however, so the entire
affair took place in the lecture hall. I think this was a good
decision, since nearly everybody was concerned about everything that
was said.
Dick Gabriel presented an entertaining history of the
background of common lisp, and then the topics on the agenda were
discussed in order for two days, at the end of which Cdr Ohlander
summarized the results of the meeting (which took about a minute). I
think most attendees would agree that the meeting accomplished little.
Some of the key points of RPG's history, I think, were the
observations that (1) the language was designed by a handful of people
doing new implementations of descendants of Maclisp, (2) they designed
the language for maximum utility to their own projects; not as a
universally useful or easy to implement language, and (3) where one of
the [self-described] "gang-of-five" required a particular feature to
be present for the evolving language to run efficiently on his
hardware, it was written into the language spec..
The implication, which seemed to have been lost on everyone
there save Carl Hewett, is that (in so far as they succeeded in #2 and
#3) the gang-of-five have no incentive whatsoever to change the
language definition that they arrived at and codified in Steele's
book.
Later Hewett kept saying [I paraphrase] "If you don't allow a
substantially broader group to rewrite the Common Lisp spec now, with
an eye towards universality, you will have 'closed the door' on the
rest of the lisp community." Typically a representative of the
gang-of-five would patiently explain that they had spent a lot time
arriving at the present spec and we would save ourselves a lot of
trouble if we simply regarded it as cast in stone; i.e. "consider the
door closed, Carl!"
One reason that the meeting went nowhere was that the issues
really on people's minds were never explicitly addressed. Eg. the
potential problem whereby two of the gang of five have a multi-million
dollar personal interest in keeping the door closed never came up.
Neither of the words "Symbolics" or "Interlisp" was ever used on the
floor. [Note: the speakers used the metonym "FU-lisp" to refer to
non-Maclisp dialects.]
Noone ever stated on the floor (though I heard it often during
the coffee breaks) that their biggest problem with Common Lisp is not
its design per se, but the fact that DARPA is insisting on the use of
full implementations of it. These people wanted nothing more than
either:
[A] official Common Lisp stripped down to a subset which could
be generated by other programming environments (eg. Interlisp-D or 9836
PSL), the goal being de facto acceptance by DARPA, or
[B] DARPA willingness to accept code in such a subset regardless of the
gang-of-five Common Lisp standard.
Cdr Ohlander only contributed to the confusion by claiming in
the last hours that #2 is already the case. This was confusing
because it stood at odds with everything he had said in the preceding
two days and with the pressure DARPA has put on contractors to buy
3600's. In fact, the purpose of the meeting (extension of Common Lisp
standards) assumed that Steele's book is cast in stone and that what
needs doing is the casting in stone of a multitude of extensions.
I will now attempt to summarize the discussion of each of the
topics on the agenda.
"Is ANSI standardization appropriate?" The consensus seemed to
be that the ANSI standardization process is too cumbersome and slow to be
of any use. The only dissenter (who didn't seem too concerned one way
or the other) thought that ANSI had been great for COBOL and might actually
be good for Common Lisp.
Steve Squires seemed delighted to nominate DARPA as the
steward of Common Lisp, citing such "successes" as ADA and IP/TCP as
examples of how good they are at such things. I personally consider
ADA and IP/TCP two of the decade's greatest design/implementation
disasters thus far, but no-one wanted to debate Squires on this point.
"What shall be the procedure by which the Common Lisp standard is
maintained?" With the exception of Richard Greenblatt, everybody seemed
to agree that there is at present no existing complete implementation of
Common Lisp. Most people seemed to agree that there should be assembled
a suite of validation tests which could discriminate between correct and
incorrect implementations, and that the tests be identifiable in such a
way that it would be useful to say "Implementation X satisfies tests A, B,
D, F, and G, but not tests C and E." No agreement was reached as to who
should collect, administer, or certify this suite. I think it was agreed
that Dick Gabriel collect them in the mean time, since he already has the
largest collection. It was also agreed that these validation tests should
have the year of their design associated with them.
"What shall be the procedure by which the Common Lisp standard
is enforced?" [not on the agenda] Cdr Ohlander told us several times
that he a squad of lawyers ready to sue people who used the Common
Lisp name without passing the validation suite. A supporter in the
audience nominated Gold Hill as the first against the wall when the
revolution comes. The DARPA people seemed hot to trade mark
everything having to do with Common Lisp they could. They were
disappointed that their lawyers told them it was too late to trademark
"Common Lisp" itself. [One card I spoke to during a coffee break
suggested that maybe some of us should get together and sue the
gang-of-five for calling a language without dynamic scoping "lisp"!]
Steve Squires presented his AAAI talk on "the
server/workstation architectural concept." Not many people thought
that this had any bearing on the design of Common Lisp (or vice
versa), so no discussion followed. [Probably 25% of the total
conference was dedicated to discussing what was worthy of discussion.]
"What shall be the procedure by which Common Lisp
evolves/expands?" I think that by this point in the conference those
of us who hoped Common Lisp might contract instead (for the reason
given in [A] above) gave up on this conference as a means to achieving
that end. Thus it seemed to be the consensus of those speaking that
the gang-of-five (or some successors) continue to review proposals and
debate/adopt them in the same manner as the original Common Lisp
proposals were adopted. Rather than discuss object-oriented
programming, window systems, graphics interfaces, iteration
constructs, database interfaces, remote user interfaces or
multiprocessing on the floor, overlapping groups of those present
signed up to be on Internet mailing lists for the discussion of each
of these topics. [I signed up for the subset discussion list, which
seemed to be most popular after the object-oriented programming list.]
--Christopher
-------
∂28-Sep-84 1448 SCHOEN@SUMEX-AIM.ARPA Re: DARPA Common Lisp Conference (long summary)
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 28 Sep 84 14:48:05 PDT
Date: Fri 28 Sep 84 14:48:21-PDT
From: Eric Schoen <Schoen@SUMEX-AIM.ARPA>
Subject: Re: DARPA Common Lisp Conference (long summary)
To: SCHMIDT@SUMEX-AIM.ARPA, Rindfleisch@SUMEX-AIM.ARPA,
Pattermann@SUMEX-AIM.ARPA
cc: RPG@SU-AI.ARPA, Feigenbaum@SUMEX-AIM.ARPA, Nii@SUMEX-AIM.ARPA,
Brown@SUMEX-AIM.ARPA, Delagi@SUMEX-AIM.ARPA, Yeager@SUMEX-AIM.ARPA,
Croft@SUMEX-AIM.ARPA
In-Reply-To: Message from "Christopher Schmidt <SCHMIDT@SUMEX-AIM.ARPA>" of Thu 27 Sep 84 16:51:50-PDT
And now for something completely different, here are my transcribed notes
on the CommonLISP meeting. The same caveats as expressed in Christopher's
message probably should hold for this one as well; I would appreciate any
clarifications or clarification requests anyone has.
Eric
REPORT ON THE COMMON LISP CONFERENCE SEPTEMBER 18-19, 1984
NAVAL POSTGRADUATE SCHOOL MONTEREY, CALIFORNIA
This memo reports on a meeting of the CommonLISP community which was held on
September 18 and 19 to discuss future directions in the development of the
CommonLISP language. The meeting was organized by Lee Baumann of Scientific
Applications International Corporation, under the auspices of DARPA. Attendees
included members of the CommonLISP development group, representatives of
computer manufacturers offering CommonLISP implementations, commercial
CommonLISP users, and university-affiliated researchers.
The major topics of discussion were as follows:
- Standardization. Development of validation suites or other official
standardizing mechanism to ensure that languages called "CommonLISP"
are indeed CommonLISP.
- Extensions to the documented CommonLISP standard. Additions to the
language specification to allow certain necessary functions to be
placed in the kernel of any CommonLISP implementation.
- Server/Workstation issues. The impact on the language of a
configuration of moderately powerful workstations with a network-
accessible high-performance Lisp server.
- CommonLISP Subset. Reduced versions of the CommonLISP language for
small machines, educational purposes, etc.
- Procedures for maintaining and extending the language. Development
of the official mechanism to handle proposed extensions,
clarifications, etc of the standard.
Standardization of CommonLISP
The major purpose behind standardizing the CommonLISP language would be to
prevent a software vendor from marketing a ``CommonLISP'' which does not in
fact adhere to the standard. Part of the standardizing process would be to
secure a trademark on the name ``CommonLISP.'' Use of the CommonLISP trademark
would thus be a ``seal of approval'' from the CommonLISP community [Scott
Fahlman]. As the language is evolving, it was suggested that trademarks be
obtained not for the generic CommonLISP name, but instead for releases of the
proposed CommonLISP validation suites, e.g. ``CommonLISP 84.''
The issue of standardizing the language through one of the existing standards
organizations (e.g., ISO or ANSI) was discussed. The general feeling was that
this was a bad idea, as the overwhelming bureaucracy this would imply would
tend to slow the development of the language at a time when rapid evolution is
foreseen.
There is some evidence that standardization does not always help to maintain
compatible versions; there are, for instance, two Pascal standards [Chuck
Hedrick]. In addition, since versions of the standard are released
infrequently (e.g., COBOL or FORTRAN experience), interim developments to the
language are made in random directions [Gordon Novak]. Finally, concern was
voiced that standardizing the language through one of these organizations could
result in the community's losing control over the language [Ron Ohlander].
The final outcome of this discussion was that standardizing be done by a
committee whose members are chosen from the CommonLISP community. The format
of this committee was discussed later under the heading of procedures for
maintaining and extending the language.
Extensions to the Standard
The purpose of this discussion was to identify those areas in the language
stand which need further extensions. Quite a large number of areas were
identified:
* *
Object-Oriented Programming Windows
*
Error Handling Multiprocessing
* *
Graphics Iteration constructs
Timing support Networking/General I/O
Database hooks Logic Programming
*
Foreign Function Call Pattern Matching & Destructuring
International Character Set Program Manipulation Tools
Type Coercion Rules Storage Management
(Resources and ``Areas'')
Each of these extensions could be grouped into one of three major areas:
- Essential for CommonLISP. That is, must be part of the language
standard so that implementations may be part of the language kernel
(either for efficiency or because no other mechanism is sufficient
for inclusion in a system).
- Part of the base for the ``Environment.''
- Interface to the external world.
No ultimate decisions were made regarding extensions. A number of observations
are worth reporting, however. Extensions to the standard should be meant to
add onto the common base; they should not cause the user to have to choose one
implementation over another [Novak]. The general feeling seemed to be to
accentuate core extensions (e.g., objects, windows, etc).
It was agreed that Internet mailing lists be established to further the
discussion of proposed extensions to the language. Mailing lists have been
*
established for those topics marked with in the list above. The results of
the mailing list discussion are supposed to be a proposed set of manual pages
for the ``white'' or ``yellow'' pages.
The extensions discussion then degenerated into another discussion regarding
copyright and reprint agreements w.r.t. the CommonLISP book between Guy Steele
and Digital Press. The authors' view here is that vendors selling a CommonLISP
should be allowed to reprint the book in its entirety, as well as make
additions to reflect their implementations of the language; they should not,
however, delete any portion of the original text. In addition, the
accessibility and completeness of online editions of the manual were discussed,
with no clear outcome.
Server/Workstation Issues
This was a short discussion led by Bob Balzer of USC-ISI. The major thrust of
his presentation was that the language architecture should permit easy
migration between moderately-powerful personal workstations and high-
performance Lisp servers. There was no clear outcome of this discussion.
Subsets of the Language
The ``subset'' discussion was intended to get some feeling of what subset of
the CommonLISP standard could be considered as reasonable for various special
purposes. Those purposes discussed were primarily:
- Educational
- Small machine
- ``Essential'' CommonLISP
The educational subset and the small machine subset will probably overlap. The
goal behind the educational subset is to document some subset of the language
to be used in teaching; teachers and textbooks on the language would restrict
themselves to this subset. Since educational machines are most likely small
machines (e.g., Macintosh), a reduced version of the language was thought to be
necessary [Novak, Steele].
Unfortunately, the attendees had divergent attitudes over the purpose of
educational subsets. One camp wanted ``some of everything.'' Another wanted
some reduced number of functions plus environmental extensions (windows and
debuggers). The difference seemed to be between those who wanted simple and
elegant semantics (a la Pascal), versus those who wanted to limit style, but
not functionality [I guess it's not too clear how different these viewpoints
really are].
One interesting set of figures came up during this discussion regarding the
size of vendors' systems. (These are the sizes of the sysouts, world loads,
image files, etc that are transferred into memory prior to starting the
systems. They do not include the size of data areas created dynamically during
system execution.)
Perq Common Lisp system 2.5 MB
Perq Common Lisp Lisp-only 1.0 MB
ZetaLisp 25 MB
Data General Common Lisp 2.5 MB
Gold Hill Lisp 128 KB(50-60% of functions in manual)
DEC VAX Lisp <3.9 MB
LMI 13-14 MB
Interlisp-D 2.5 MB
At this point, the discussion was turning towards ``essential'' CommonLISP,
that is, the subset of CommonLISP necessary to achieve the goals of contractors
in the Strategic Computing effort. The primary purposes for this subsetting
were:
1. Efficiency of implementation. Stock hardware. The last 5% of the
CommonLISP implementation impacts the performance of the remaining
95% of the system [Gabriel].
2. Compatibility for other Lisps. Representatives of the PSL, Franz
Lisp, and Interlisp development groups in attendance asked for some
unambiguous subset to be established which they could implement on
top or inside their systems. This spawned a sub-discussion on what
is necessary in a Lisp for it to be CommonLISP. While no clear
answer was formulated, it seemed that the language would have to
supply upward-directed lexical closures, lexically-scoped go-tags,
and multiple-valued returns [Note: These are necessary, but
insufficient conditions].
It was clear that the group desired to unify the rather disparate
Lisp communities which now exist; subsetting CommonLISP to allow the
non-ZetaLisp, non-MACLisp users to migrate towards CommonLISP was
viewed as an acceptable strategy. Ohlander declared that DARPA
would accept some ``production-quality'' subset whose definition
remains to be specified. An additional Internet mailing list was
formed to continue this discussion.
Procedures for Extending and Maintaining CommonLISP
This final discussion pertained to the official mechanism by which CommonLISP
will be maintained and extended. This section was led by Scott Fahlman, who
began by describing the method the language designers used in coming up with
the original specification (netmail discussions, decisions by consensus or
ballot).
This portion of the conference was reasonably non-controversial. The major
questions had to do with keeping the decision-making process as open as
possible to avoid anti-trust suits [Hewitt]. The mechanism to be set up
consists of:
1. The CommonLISP community interacting via Internet mail.
2. An executive committee, with an acting chairperson. The function of
this committee is to monitor netmail discussions of various issues
and to be sensitive to consensus.
3. An administrative committee (needs funding!) to handle paperwork.
4. A ``Q&A'' service for implementors; designed to provide quick
response to questions.
5. A news service to advertise design decisions; archival storage of
notices; periodic hardcopy distribution of archives to members whose
Internet access precludes bulk file transfer.
6. A ``delta'' document consisting of clarifications and updates to the
manual.
7. Periodic new editions of the manual.
8. Periodic (about yearly) releases of the test/validation suite.
9. Implementation notes.
10. ``Yellow'' pages library and distribution mechanism.
The members of the executive committee will be drawn from the CommonLISP
community in the following sectors:
- Companies
- DoD
- Universities
- Individuals (i.e., the original designers)
Questions such as veto power and voting apportionments to companies and the
original designers remain to be answered. Further, the proportion of vendor
companies vs. user companies is undecided. Temporarily (next six months), the
executive committee will be composed of the original designers (Steele,
Fahlman, Gabriel, Moon, Weinreb).
-------
∂28-Sep-84 1546 RINDFLEISCH@SUMEX-AIM.ARPA Jay Lark: DARPA Common Lisp Conference
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 28 Sep 84 15:46:33 PDT
Date: Fri 28 Sep 84 15:46:44-PDT
From: T. C. Rindfleisch <Rindfleisch@SUMEX-AIM.ARPA>
Subject: Jay Lark: DARPA Common Lisp Conference
To: SCHMIDT@SUMEX-AIM.ARPA, Pattermann@SUMEX-AIM.ARPA, Schoen@SUMEX-AIM.ARPA,
RPG@SU-AI.ARPA, Feigenbaum@SUMEX-AIM.ARPA, Nii@SUMEX-AIM.ARPA,
Brown@SUMEX-AIM.ARPA, Delagi@SUMEX-AIM.ARPA, Yeager@SUMEX-AIM.ARPA,
Croft@SUMEX-AIM.ARPA, Rindfleisch@SUMEX-AIM.ARPA
In-Reply-To: Message from "Christopher Schmidt <SCHMIDT@SUMEX-AIM.ARPA>" of Thu 27 Sep 84 16:51:59-PDT
From: Jay S. Lark (Teknowledge, Inc.)
Subject: DARPA Common Lisp Workshop
Date: Thursday, September 20, 1984
This is my report of the first DARPA Common Lisp Workshop, held
September 18 and 19 at the Naval Postgraduate School in
Monterey. This was the first meeting of the Common Lisp
community as a whole; particpants included the language
designers and implementors, DARPA, vendors, consumers, and
other interested individuals. The total number of attendees
was close to 100.
In this report, I will first summarize each of the major topics
that were discussed. I will then present my general
impressions of the workshop.
Opening Remarks Ron Ohlander
Ron gave a brief introduction to the participants. He stated
the objectives of the workshop in the form of an agenda:
- Is ANSI standardization apropriate?
- How are Common Lisp implementations to be validated?
- Are subsets or supersets of Common Lisp apropriate?
- Is Common Lisp adequate to implement the
server/workstation architecture?
- How is Common Lisp to be maintained, and what are the
procedures for maintenance and evolution of the
language?
Ron expressed DARPA's concerns for standardization on a Lisp in
order to promote greater portability and understanding of code,
and as a method for integration of the various software modules
of DARPA's Strategic Computing Project.
Target vs. Development Environments Steve Squires
Steve gave a presentation of his ideas of computing
environments. The main thrust of his arguments were that
Common Lisp, as specified in the book with extensions for
user-interfaces, graphics, networking, etc., is an apropriate
delivery environment. It is expected that the programming
tools that will inevitably be developed for Common Lisp by the
vendors will provide the development environment. He called
this the embedded system model, and related it to the
server/workstation architecture (more on this later.) The only
lasting point I took out of this talk was the need for
tools/methodologies to facilitate the process of tranfering
software from development to target environments.
On a different matter, Ron mentioned that he will be leaving
DARPA next summer, and that Steve Squires will be taking his
place. My initial impressions of Steve were that he was
skilled as a researcher, but didn't have the savvy to fill
Ron's shoes.
A Brief History of Common Lisp Dick Gabriel
RPG has always been known for enternaining, tongue-in-cheek
talks, and this was no exception. The content of this talk is
not particularly important, except for two points: Common Lisp
is largely a product of the ARPANET, and our own Bob Engelmore
was the man behind the 1981 ARPA Lisp Conference at SRI, where
the original Common Lisp co-conspirators first met and devised
the language. The importance of the ARPANET as a design forum
was stressed several time throughout the workshop, and future
activities relating to Common Lisp will continue to use the
net.
ANSI Standardization Group discussion
After considerable group discussion, a consensus of sorts was
reached. It was decided that at this point it is far to early
to expect the language to be stable enough to benefit from ANSI
standardization. This discussion did raise the hairy point of
validation of Common Lisp implementations. The concern was
raised that an incomplete test suite would not be useful,
whereas a complete test suite would usurp the language
definition from the book. I think the consensus was that some
test suite be available to validate Common Lisp
implementations, but the developer/owner of that test suite was
still an open question. Several comparisons were drawn to ADA,
indicating some lessons to be learned.
Extensions to Common Lisp Guy Steele
This was the most spirited session of the first day. After
much discussion, the following list was agreed upon as possible
areas for the Common Lisp standard to extend to.
- foreign function calls
- object-oriented programming
- screen management, windows
- error handling
- multiprocessing
- graphics
- iteration
- networking
- function timing and other instrumentation
- access to databases
- destructuring
- international character sets
- program manipulation tools
- pattern matching
- type coercion rules
- software configuration and management tools
- storage management, areas
- resources, as in ZetaLisp
Each of these topics were put to a vote on whether they would
be fruitful to explore with further discussion. Only the first
six passed the vote, and subcommittees were formed to study
each of the issues in more detail (more on subcommittees
later.)
At the meta-level, there was also considerable disagreement on
whether to extend the language at all, and if so, how should it
be done. Three basic arguments were presented, roughly
representing the language designer, sophisticated users and
language implementors/vendors, and consumers.
1. The designers, represented by Kent Pitman and
Richard Zippel, saw Common Lisp as a common starting
point to do language research and development from;
in effect, Lisp 2.5. As such, extensions in the
above areas are not at all desirable, and should not
be included at all in the language specification.
2. The sophisticated user and vendors, represented by
Scott Fahlman and Bob Balzer, also argued that the
extensions do not belong in the language spec.
However, they felt that all the low-level hooks
needed to efficiently implement any of the
extensions should be included in the spec. In this
way, different extensions could be shared across
implementations, without casting the extension
itself in stone.
3. The consumers, represented by myself, argued that
unless a particular extension was standardized, it
would not be useful to us. In general, a consumer
wouldn't have the resources to implement their own
particular extension, but at the same time relying
on any particular vendors's implementation of an
extension would tie us to that vendor, defeating the
whole purpose of standardization. This point was
lost on most of the participants, but Ohlander
picked up on it and said it was a concern to DARPA
as well.
Server/Workstation Architecture Bob Balzer
I think there was some kind of conspiracy to slip this into the
agenda. I don't think anyone really knows what this has to do
with Common Lisp. Even so, they still managed to discuss it
for almost an hour.
Common Lisp Subsets Ron Ohlander
This was also a topic that generated a lot of discussion. The
following were the main points:
- Why do subsets?
* for small machines, "where every MB counts"
* as delivery vehicles
* as a method of bringing other Lisp dialects into
the fold
* for people who either don't need or want to pay
for all the features
* for education
- Is a subset of Common Lisp still Common Lisp? How do
you validate subsets? Should they even be called
Common Lisp?
- What are the features that may be left out of a
subset:
* lexical scoping of GO tags
* upward funargs
* lexical scoping altogether
* multiple values
* complex numbers
* packages
* keywords
- What subset of Common Lisp could other Lisps, such as
PSL, Franz, or InterLisp easily implement. It was
suggested that none of the other dialects could ever
be made to be Common Lisp without major design mods,
but they could get halfway. Somebody then noted that
the halfway point for all three dialects would be
very similar, and represents an implicit subset of
Common Lisp.
The concensus that Ron pulled from the discussion was that:
- The community shouldn't worry about educational
subsets.
- The Common Lisp standard is the book; any subset is
not Common Lisp.
- Work should start (and indeed a subcommitte was
formed) to define a production quality subset of
Common Lisp for the Strategic Computing Project.
Common Lisp, the Bureaucracy Scott Fahlman
This discussion focussed on the procedures for maintaining and
evolving the Common Lisp spec, disseminating information, and
deciding future directions for development. In summary, the
following organization was proposed.
The Common Lisp community would be represented by a congress
(my term), which would meet yearly to ratify major extensions
to the spec, provide new directions, etc. The workshop is the
prototype of this group. Membership in the congress would be
broad-based, with representatives from industry, acedemia, DOD,
and other interested individuals. Each organization would buy
into the congress, possibly with the fee to cover
administrative costs, and would receive a single vote, although
they may send delegations consisting of several individuals.
The congress would elect an executive committee, consisting of
less than ten individuals. This committee would coordinate the
activities of the individual subcommittees, schedule meetings,
determine consensus, and provide overall leadership. The
powers of the committee to force language decisions would be
very restricted.
Several subcommittees will be formed out of the congress to
investigate language extensions, subsets, validation, etc.
Membership would be on a voluntary basis. The subcommittees
would report to the executive committee, and any specific
proposals would require ratification of the congress as a
whole. The subcommittees will work over the ARPANET.
A separate administrative body would be formed to handle the
paperwork for all the subcommittees. It would receive funding
from the member organizations and/or DARPA.
A subcommittee was formed to create a charter for all of this,
and another meeting of the community was tentatively scheduled
for six months from now to ratify the charter.
IMPRESSIONS
The preceeding was a summary of the actual discussion that took
place at the workshop. In the next few paragraphs I am going
to attempt to summarize my impressions of the workshop, and
where the Common Lisp community is going.
I was impressed by the enthusiasm of the participants. I think
everybody left in very high spirits. There was some
substantial work done in building up an organization to support
Common Lisp in its "fragile" infancy. Several subcommittees
have been formed to investigate specific extensions, and a
charter is on the way. Overall, it was a very productive
workshop.
My main concern is that the community, as defined by the
participants at the workshop, is still very slanted away from
the users of the language. Subsequent workshops must endeavor
to gain greater representation from industrial consumers of the
language. Oddly enough, the designers and academians who first
called for standardization of Lisp represent the greatest
threat to the eventual adoption of Common Lisp as a standard.
Common Lisp is for real; there is no doubt about that.
Ohlander indicated that DARPA will require delivery in Common
Lisp by 1986. There should be about half a dozen solid
implementations of the language within the next year, with more
hardware manufacturers and software houses to follow.
It is too early to predict the long-term evolution of Common
Lisp. By the next congress six months from now, the possible
paths of development will be clearer. I would predict a period
of consolidation in the short term, with little language
development but significant organization development.
-------
Cannery-row Lisp
Chris,
I'd like to offer some mild rebuttals to your recollections of the
Monterey meeting.
The first regards my history speech. You said that I stated that the then
current implementations had an undue influence over the design of Common
Lisp. Although the influences of the then current implementations were
constantly present, a great deal of the explicit thinking of the committee
was about what constituted a good Lisp dialect. For all but the last few
months ofthe design period, decisions were mainly by consensus over a very
wide audience (over 50 people). These people included PSL, Franz, and
InterLisp hackers.
If we designed a language of maximum utility to our own projects, that was
largely a coincidence, modulo the constant influences I mentiond above.
This member of the gang-of-5 did not succeed entirely in calming the array
waters: I proposed a simpler array mechanism than appears in the current
Common Lisp specification.
Let me address an underlying implication of your message, the implication
being: The Common Lisp designers were a cloistered set of MacLisp hackers who
intentionally cut off the rest of the world from the design process.
This is incorrect on some very important levels, although it could be argued
to be superficially true.
When I was gathering the forces that were to make up the Common Lisp
group, I recruited every major dialect of Lisp. That is, I explicitly went
after Franz Lisp, PSL, InterLisp (in the form of Xerox), UCILisp, and even
T. I argued that is was time that the entire Lisp community should unit.
To this end, I had many discussions with Xerox folks and with Ed
Feigenbaum, who championed InterLisp at Stanford and at large. Although I
convinced Feigenbaum. I did not convince Xerox, although I wouldn't say
that that failure was anything but a symptom of Xerox's bad
decision-making in general or of its limited resources.
My intention was to do the Lisp design for the '80's and '90's once and for all.
When the Common Lisp group was doing its work, we thought we were designing the
last word in Lisp, at least from a political standpoint. We all knew that
Common Lisp was not the best Lisp we could do, but it was the best under the
prevailing political realities. Had Xerox joined in, the political realities
would have been that much different, and so would the resulting language.
I don't think that what you quoted Carl Hewitt correctly I thought he was
saying that unless the future control of Common Lisp is opened up to
groups with commercial interest in Common Lisp, this closed door policy
will be illegal. I don't think that he was saying that now that we've seen
that divergent groups *can* get together, the rest of us should design yet
another Common Lisp.
Before relegating Symbolics to the realm of pure capitalists, think a little
bit about what their participation in the Common Lisp design effort meant.
If they wanted to claim a whole segment of the Lisp market with an exclusive Lisp,
why would they have joined? Their motivation was that if they were to capture
a larger market, then the market would have to grow - they already had a
lion's share of the existing one. To do that, they would have to help the Lisp
market get bigger, which can only happen if the same Lisp that ran on their machines
ran on stock machines too. This way, more people would be able to get into the
Lisp world, and the market ould get bigger. Maybe their share would decrease,
but the total would increase.
Had Xerox wanted to join in, then the Symbolics people might have reasoned
that getting Xerox and Symbolics to support the same Lisp would open up
the Xerox market to Symbolics, and the comparison between Xerox and Symbolics
would be on the basis of the merits of the respective iron and on the quality and
quantity of the code to support users.
Symbolics' staff overwhelms Xerox's, so Xerox can only compete in the
support-code area by using the many years of code development already in
existence. Symbolics competes using the many excellent programmers who can
make up ground fast. I would say that the rational decision for Symbolics
is to woo Xerox and InterLisp, and the rational decision for Xerox is to
pooh-pooh standardization with Symbolics. I think history backs up this
analysis.
The multi-million dollar interest in Common Lisp that Moon and Weinreb
have was created over the 3.5 years that we spent doing the design, and is
being paid for with many man-years of code changes to ZetaLisp that Common
Lisp requres. I can assure you that Moon and Weinreb acted more like
academics than capitalists throughout the entire design process, and my
observation is that Symbolics management often looked with horror at what
these guys were doing.
The reason the gang-of-5 loathes changing Common Lisp now is that we
didn't go through this exercise simply to prove that diverging attitudes
in Lisp could finally get together to do a common design, and that now
that that has been proven as possible the real design can start. I made no
secret of what we were up to throughout the the course of the Common Lisp
design, and I made damn sure people new we were attempting to do the final
Lisp design for the next decade or so. The commercial attitude of Xerox
and the not-invented-here attidude of PSL doesn't much impress me at the
moment.
I think that DARPA's attitude in this is understandable and appropriate:
We volunteered the valuable time of dozens of the best Lisp implementors
to do a public service, and by now supporting the fruits of that effort,
DARPA informs the world that the spirit of community we showed is to be
rewarded. How many years did DARPA try to get the Lisp world to unite?
Dynamic scoping: Many people claim that this implementation pun of the
late '50's is *the* hallmark of Lisp. On the other hand, I spend more time
debugging other peoples' Lisp programs on the basis of the different
implementations of binding in the compiler and interpreter than any other
sort of bug. Compiler-writers want lexical scoping, programmers make fewer
mistakes when they use lexical scoping, lexical code is easier to
understand, and Lisp programmers really mean lexical scoping 90%-99% of
the time. Lexical scoping helps solve the `funarg' problem, and finally
closures can be provided to the programmer for use.
Would you mind if I sent your comments and my reply to Scott Fahlman for
his comments?
-rpg-
∂01-Oct-84 1856 SCHMIDT@SUMEX-AIM.ARPA Re: Cannery-row Lisp
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 1 Oct 84 18:56:37 PDT
Date: Mon 1 Oct 84 18:57:08-PDT
From: Christopher Schmidt <SCHMIDT@SUMEX-AIM.ARPA>
Subject: Re: Cannery-row Lisp
To: RPG@SU-AI.ARPA
In-Reply-To: Message from "Dick Gabriel <RPG@SU-AI.ARPA>" of Mon 1 Oct 84 11:05:00-PDT
I don't mind if you send my comments and yours to Scott Fahlman.
I'm not sure what interest they would be of to him. I believe that my
motivations are pretty well known to the people who received my letter and
may be obscure to him.
For his benefit: I am responsible for the maintenance of and
counseling of the users of 22 Interlisp-D machines, 4 9836's, and 4
3600's. D machines and 9836's are readily available to me, but I have
to walk a mile to get to the nearest 3600. At the end of the year,
I will have 35 D machines, 4 9836's, and 8 3600's to worry about. SUMEX
will have moved and it will be a 2 mile walk to the nearest 3600. I
have already resigned that portion of my job dealing with 3600's, so
my interest in them (and Common Lisp) is almost purely academic. Before
making this decision, I had decided that there was more money/future
in the 3600/Common Lisp direction, and spent several weeks trying to
convince myself that I could live with the latter. To make a long
story short, I ended up convincing myself instead that there is more
sanity in sticking to Interlisp-D no matter how non-standard it is.
I just can't stand editing lisp programs with a text editor.
Furthermore, the Common Lisp comment syntax precludes using a structure
editor, so I have little hope that the Common Lisp people will (or
can) ever see the light in this regard. I prefer TOPS-20 over unix,
Scribe over troff, the Z editor over EMACS, C over Pascal, and PUP
over IP/TCP. In short, I have little regard for "obvious standards" and
I am unrepentant about it. Fortunately, SUMEX is sympathetic to TOPS-20,
Scribe, Z, C, and PUP, so I am in a pretty good situation. I do feel
threatened now, however, since the HPP is giving serious consideration
to imposing a police state in which no lisp but Common Lisp is allowed.
If I seem to have an anti-Common Lisp tone, it is not because I bear
you any ill will; it is because I personally don't want to be forced
to give up Interlisp-D, which is what the police state would mean for me.
I have some reactions to your mild rebuttals.
The first regards my history speech. You said that I stated that the
then current implementations had an undue influence over the design of
Common Lisp.
I don't think I said this explicity, but I did mean for the reader
to conclude it. I based the statements I did make primarily from the
chart you put on the overhead projects.
Although the influences of the then current implementations were
constantly present, a great deal of the explicit thinking of the
committee was about what constituted a good Lisp dialect. For all but
the last few months ofthe design period, decisions were mainly by
consensus over a very wide audience (over 50 people). These people
included PSL, Franz, and InterLisp hackers.
I would be more easily convinced of this if the resulting language wasn't
almost indistinguishable (in my eyes) from Zetalisp.
If we designed a language of maximum utility to our own projects, that
was largely a coincidence, modulo the constant influences I mentiond
above. This member of the gang-of-5 did not succeed entirely in
calming the array waters: I proposed a simpler array mechanism than
appears in the current Common Lisp specification.
This is a perfect example of annoyingly unnecessary complexity. I wish
you had been more successful in your efforts.
Let me address an underlying implication of your message, the
implication being: The Common Lisp designers were a cloistered set of
MacLisp hackers who intentionally cut off the rest of the world from
the design process.
I didn't mean to imply any malice on the part of the designers. The
resulting spec, however, makes it next-to-impossible to port the
Interlisp-D programming environment to, however.
This is incorrect on some very important levels, although it could be
argued to be superficially true.
When I was gathering the forces that were to make up the Common Lisp
group, I recruited every major dialect of Lisp. That is, I explicitly
went after Franz Lisp, PSL, InterLisp (in the form of Xerox), UCILisp,
and even T. I argued that is was time that the entire Lisp community
should unit.
This is not the same as saying that they did unite, however, and the
spec shows it. What amazes me is that you have convinced so many people
that you succeeded.
To this end, I had many discussions with Xerox folks and with Ed
Feigenbaum, who championed InterLisp at Stanford and at large.
Although I convinced Feigenbaum.
I would be more likely to be persuaded by this argument if I believed
that Ed Feigenbaum (or Tom Rindfleisch) had written 10 lines of lisp
code in the last year. Neither (to my knowledge) has
substantial experience either with a D machine or with a 3600.
I did not convince Xerox, although I wouldn't say that that failure
was anything but a symptom of Xerox's bad decision-making in general
or of its limited resources.
I agree.
My intention was to do the Lisp design for the '80's and '90's once
and for all. When the Common Lisp group was doing its work, we
thought we were designing the last word in Lisp, at least from a
political standpoint.
A noble goal, but I don't believe that it was acheived. Want to take a whack
at "Portable Common Lisp?" <:-)
We all knew that Common Lisp was not the best Lisp we could do, but it
was the best under the prevailing political realities. Had Xerox
joined in, the political realities would have been that much
different, and so would the resulting language.
A good ombudsman would accomodate the other camp even where the other camp
was uncooperative. I think this was your greatest mistake if you really
did want to unite the lisp communities.
I don't think that what you quoted Carl Hewitt correctly I thought he
was saying that unless the future control of Common Lisp is opened up
to groups with commercial interest in Common Lisp, this closed door
policy will be illegal. I don't think that he was saying that now that
we've seen that divergent groups *can* get together, the rest of us
should design yet another Common Lisp.
You're right. This wasn't a quotation. It was the overlap of the
predicates of several of his statements and the conclusion I drew from
them. I shouldn't have coupled it so closely to his name.
Before relegating Symbolics to the realm of pure capitalists, think a
little bit about what their participation in the Common Lisp design
effort meant. If they wanted to claim a whole segment of the Lisp
market with an exclusive Lisp, why would they have joined? Their
motivation was that if they were to capture a larger market, then the
market would have to grow - they already had a lion's share of the
existing one. To do that, they would have to help the Lisp market get
bigger, which can only happen if the same Lisp that ran on their
machines ran on stock machines too. This way, more people would be
able to get into the Lisp world, and the market ould get bigger. Maybe
their share would decrease, but the total would increase.
I think they played this thing like a violin.
Had Xerox wanted to join in, then the Symbolics people might have
reasoned that getting Xerox and Symbolics to support the same Lisp
would open up the Xerox market to Symbolics, and the comparison
between Xerox and Symbolics would be on the basis of the merits of the
respective iron and on the quality and quantity of the code to support
users.
I would like Xerox and Symbolics to be compared on the basis of the merits
of the respective iron and the quality and quantity of the code to support
users. What I don't like is for them to be compared in their abilities
to assimilate an arbitrary spec--particularly one which was based
heavily on the Symbolics product.
Symbolics' staff overwhelms Xerox's, so Xerox can only compete in the
support-code area by using the many years of code development already
in existence. Symbolics competes using the many excellent programmers
who can make up ground fast.
I think they are about tied at about a dozen excellent programmers each.
The Xerox wizards are available to us at Stanford, however, whereas
Symbolics has forbidden us ever to communicate with their programmers
directly. I realize that this the case for Xerox customers in foreign
lands as well, but they are not my problem.
I would say that the rational decision for Symbolics is to woo Xerox
and InterLisp, and the rational decision for Xerox is to pooh-pooh
standardization with Symbolics. I think history backs up this
analysis.
I agree, and I think your spec makes it hard for either party to do otherwise.
The multi-million dollar interest in Common Lisp that Moon and Weinreb
have was created over the 3.5 years that we spent doing the design,
and is being paid for with many man-years of code changes to ZetaLisp
that Common Lisp requres. I can assure you that Moon and Weinreb acted
more like academics than capitalists throughout the entire design
process, and my observation is that Symbolics management often looked
with horror at what these guys were doing.
As mentioned earlier, I would be more easily convinced of this if the
resulting language wasn't almost indistinguishable from Zetalisp.
The reason the gang-of-5 loathes changing Common Lisp now is that we
didn't go through this exercise simply to prove that diverging
attitudes in Lisp could finally get together to do a common design,
and that now that that has been proven as possible the real design can
start. I made no secret of what we were up to throughout the the
course of the Common Lisp design, and I made damn sure people new we
were attempting to do the final Lisp design for the next decade or so.
I understand. DARPA made damned sure people know ADA is the final systems
programming language for the next decade or so. That doesn't imply a
fait accompli.
The commercial attitude of Xerox and the not-invented-here attidude of
PSL doesn't much impress me at the moment.
Self-annointed standards committees don't impress me much, either.
I think that DARPA's attitude in this is understandable and
appropriate: We volunteered the valuable time of dozens of the best
Lisp implementors to do a public service, and by now supporting the
fruits of that effort, DARPA informs the world that the spirit of
community we showed is to be rewarded. How many years did DARPA try
to get the Lisp world to unite?
So are they interested in AI research or fighting a religious war?
My contention is that their preoccupation with the latter has harmed
their ability to pursue the former.
Dynamic scoping: Many people claim that this implementation pun of the
late '50's is *the* hallmark of Lisp. On the other hand, I spend more
time debugging other peoples' Lisp programs on the basis of the
different implementations of binding in the compiler and interpreter
than any other sort of bug. Compiler-writers want lexical scoping,
programmers make fewer mistakes when they use lexical scoping, lexical
code is easier to understand, and Lisp programmers really mean lexical
scoping 90%-99% of the time. Lexical scoping helps solve the `funarg'
problem, and finally closures can be provided to the programmer for
use.
I agree. This is a great waste of time in debugging others' code for
me as well. I personally never use special variables. The comment
was meant to lighten up my letter a little.
--Christopher
-------
∂01-Oct-84 2210 FAHLMAN@CMU-CS-C.ARPA Cannery Row Lisp
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 1 Oct 84 22:10:11 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Tue 2 Oct 84 01:10:57-EDT
Date: Tue, 2 Oct 1984 01:10 EDT
Message-ID: <FAHLMAN.12052127000.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: schmidt@SUMEX-AIM.ARPA
Cc: rpg@SU-AI.ARPA
Subject: Cannery Row Lisp
Christopher,
Dick Gabriel sent your comments on to me -- I had been asking him what
sorts of vibes he was picking up in the aftermath of the meeting. I'm
sorry to learn that you (and therefore probably many others) are feeling
so unhappy about how things have worked out. I'm not sure that the
Common Lisp and Interlisp worlds are so irrevocably split as you think.
In particular, I don't see why the Common Lisp comment syntax would make
an Interlisp-like structure editor impossible -- can you elaborate on
what you think the problem is?
Perhaps there are still some things that both sides can do (short of
throwing away the Common Lisp design and starting over) that would
create a situation in which Interlisp and Common Lisp can coexist
peacefully. I have some ideas about this, but am too tired right now to
describe them coherently. I can't speak for the others, but my own view
is that if Common Lisp cannot win users over on its merits (or on the
merits of being a part of this large and growing user community), nobody
should try to force users to abandon the systems they prefer. There may
be large projects that have to settle on one system or another, but such
enforced standardization should only occur where it is really necessary
and we should make every effort to minimize the obnoxiousness of such
decisions as seen by indivduals who prefer other systems.
I'll try to collect my thoughts on this and send you something in the
next day or two. In the meantime, one (probably dumb) question: what's
a 9836? I tend to confuse machines when they go by numbers rather than
names.
-- Scott
∂02-Oct-84 1159 SCHMIDT@SUMEX-AIM.ARPA Re: Cannery Row Lisp
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 2 Oct 84 11:59:28 PDT
Date: Tue 2 Oct 84 11:59:04-PDT
From: Christopher Schmidt <SCHMIDT@SUMEX-AIM.ARPA>
Subject: Re: Cannery Row Lisp
To: Fahlman@CMU-CS-C.ARPA
cc: rpg@SU-AI.ARPA
In-Reply-To: Message from ""Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>" of Mon 1 Oct 84 22:11:10-PDT
As usual, you (and Dick) are perfectly reasonable and
understand the situation perfectly. My problem is that I am faced
with employers who believe that the move from Interlisp-D to Symbolics
Common Lisp is as natural and desirable as moving from Fortran 66 to
Fortran 77. They also believe that their argument is so persuasive
that I should be willing to give up the Dolphin in my office for a 25%
share in a 3600 a mile away and a promise that some time "just around
the corner" the 3600 (or whatever) will be cheap enough that I can have
one, too. You wouldn't ask me to do this, but this is what I am being
asked to do, in the name of common lisp.
Although I could dump a function edited with the Interlisp-D
structure editor (DEdit--not the Interlisp-10 editor) in a format
readable by Common Lisp, the reverse is not true. Actually, this is
not a big obstacle since the Interlisp compiler already detects where
the value returned from a comment is used, and one could fix up
text editor generated code relatively easily.
As with most Interlisp/Common Lisp problems, the key word is
@i(could). As a user or implementer, I agree that our worlds are not
irrevocable split. From Xerox's point of view, however, there are
two large classes of customer. The first group likes the Interlisp-D
programming environment and aren't unhappy with the lisp. Making Common
Lisp available will not sell any more machines to these people. The
second group is funded in large part by DARPA. A number of key people inside
Xerox would like to enter this market as well and wish to implement
some variant of Common Lisp. The problem is that they fear (and I
believe legitimately) that after putting many man years into the effort
that DARPA will say "Nice try Xerox, but we really wanted 3600's anyway."
You know as well as I do that almost any implementation could be
disqualified if one wanted to be picky and that was one's goal. I think
Ohlander made it perfectly clear that he intends DARPA to be picky.
Furthermore, Xerox fears that these committees will extend the
spec from 200 pages to 1000 and they'll never catch up and qualify to
sell their machines to DARPA. Here, too, Ohlander made clear his intent
to extend the spec., and those assembled seemed to agree that this is
a good idea. DARPA aside, I think this would put Common Lisp in danger of
collapsing under its own weight. It's already pretty close to that point.
The 9836 is a 68000 based PC made by Hewlett-Packard. It runs
PSL, Scheme, or unix. Shortly, PSL will run under unix. The implementation
is very lean and runs very fast for a 68000; beating the Dolphin in several
benchmarks. They were a gift and we intend to buy no more. They were a
terrific boon to us in that we got all sorts of nifty periferals (eg. 8 color
displays, a color plotter, 4 graphics tablets). We are enslaving a number
of the periferals to a D machine which has been fun.
SUMEX has thought about doing a port of Common Lisp to the
D machine on its own (since we have so many), which would satisfy no
spec but our own. Basically, it would be available as an auxilliary lisp
listener inside the Interlisp-D environment. Do you think that this could
be done in less than a man-year (given the same code you used for the
DEC and Perq implementations)? Is the latter code available over the
ARPA net?
Thanks for your concern,
--Christopher
-------
More Cannery-row Lisp
Chris,
``Furthermore, the Common Lisp comment syntax precludes using a structure
editor, so I have little hope that the Common Lisp people will (or
can) ever see the light in this regard.''
If you grant that the Common Lisp syntax is similar to MacLisp comment
syntax, then I can provide you with a constructive proof that one can
write a structure editor for Common Lisp: In 1973 I wrote one. It was patterned
after the InterLisp structure editor, but it had a few pattern matching features
that I thought were nicer than the ones in InterLisp. I used normal
MacLisp comments ;which look like this
;;; or which
;;; look like
this.
and the structure editor moved stuff in and out of files in such a way that
I could use a text editor on it in the meantime. I suspect that to do a structure
editor `right' these days is a little more involved than the minor hacking I
was doing then, but I presume that the belief that Common Lisp precludes anything
in the InterLisp environment is a symptom of laziness rather than clear thinking.
`Seeing the light,' to me, means that every attitude about how to build systems
using whatever tools one wants should be do-able in the language. In this case,
`seeing the light' would mean that the structure editor style should be easily
do-able. I've done a lot of large-system developement in InterLisp and MacLisp,
using structure and text editors in both worlds. I happen to prefer using the
same editor for every editing-like task. I've rigged up an interface between
the SAIL editor E (which is not EMACS, which I do not prefer) and the rest
of the system. The operating system looks like E to me, not like TOPS-10 or
Lisp. I want to do thinks my way; you want to do things your way; the light
is apparent.
``A good ombudsman would accomodate the other camp even where the other camp
was uncooperative. I think this was your greatest mistake if you really
did want to unite the lisp communities.''
On the issue of how much further we could have gone towards uniting the community
without their co-operation, or how much simpler the language could have been,
let me say the following.
Even getting the people involved - notably the liberal, add-it-all people
from Symbolics and the conservative, keep-it-simple people from CMU - to
stay in the same room together talking was tough enough. Imagine having
Reagan and Chernenko in the same room and trying to satisfy Khomeni at the
same time.
``I think they played this thing like a violin.''
I wish Xerox had.
``I would be more easily convinced of this if the resulting language wasn't
almost indistinguishable (in my eyes) from Zetalisp.''
The basic decisions of the Common Lisp group are, I think, defendable. Lexical
as the default with dynamic by special declaration isn't really much different
from what modern compilers do anyway. The lambda-list syntax cleans up the
mess in the MacLisp, which had funny LEXPR's and made &optional args etc
out of that, and it generalizes the default-to-NIL syndrome in InterLisp.
Multiple values proved useful to many people, and they eliminate the need
for a lot of weird code, like CONSing up a value so that NIL, meaning
no values returned, could be distinguished from NIL, there is one
value: NIL.
Lexical scoping also allows some sort of funargs to be done reasonably.
The array situation is a bit of a mess, the sequence functions are possibly
a bit much, FORMAT is pretty much a loser. Other than that, I think that
if you want to solve the problems that Common Lisp tries to solve, the
solutions are pretty straightforward.
Why is Common Lisp so big? First of all, a lot of people suggested making it
along the lines of Lisp 1.5 or Standard Lisp. That is, they suggested we make
it the intersection of the Lisps around. Thank God I don't have to program
in Standard Lisp. Also, we didn't want programmers to have to re-invent the
wheel. Why do MEMBER over and over, possibly incompatibly.
After 25 years we've got some idea what functions people want to use,
and we may as well standardize on them. We wanted Common Lisp to
be a Lisp that people could use without having to add reams of other code.
It is not supposed to be a minimal Lisp, but a standard, usable one.
The sad fact is that the underlying InterLisp is pretty old and primitive.
I think that Common Lisp can accomodate the CLISP syntax on top, and DWIM
can probably be implemented much more nicely in Common Lisp than in the
underlying InterLisp.
The only thing I think you'd have to give up is spaghetti stacks; and whom do
you know that uses them in a non-trivial way?
My point about Symbolics' versus Xerox strategy was meant to be a statement
about day 0 of negotiation. If Symbolics could pull Xerox away from InterLisp
as far away as Xerox could pull Symbolics away, then I think Symbolics
should rationally go for that. I.e. Pick the midpoint between ZetaLisp and
InterLisp.
Symbolics has, I think, more like a 5 to 1 advantage over Xerox. Masinter
and Vanmelle are very good, Purcell is OK, Jonl White has some management
problems, but is good. Symbolics has Moon who is unparalleled, Weinreb who
is better than Masinter, Howard Cannon is superb, Bruce Edwards is very good,
Bob Kerns is very good, Alan Bawden is very good, Bernie Greenberg is very good,
and there are about 15-20 others, each better than the individuals
at Xerox who come after those I've listed. Xerox admits they don't have
the horses to compete head to head with the hackers at Symbolics. But this
doesn't matter too much: I'll get back to that in a moment.
``Self-annointed standards committees don't impress me much, either.``
The job would not have gotten done within the political context of the
times (1981) without volunteerism. The alternative would be for ARPA to
have commissioned such a committee, and if they had done that, the same
people would have volunteered. Only the threat of `...and the language
you design will be required in 1986'' would have gotten Xerox and
Symbolics together.
``Ohlander made it perfectly clear that he intends DARPA to be picky.''
This is, I think, not correct. I've talked extensively with these guys
about Common Lisp and Xerox. As you may have heard, discussions between
the Common Lisp group (starting with me representing Common Lisp) start
tomorrow (I hope). We hope to define a subset of Common Lisp that
maybe moves a bit towards what InterLisp needs, and this subset might
be what DARPA requires. DARPA has already made an exception
to Common Lisp - Ohio State.
``So are they interested in AI research or fighting a religious war?''
DARPA wants to do research. Tolerating silly religious wars is against
that goal: All they want to do is to build on the various projects done,
not re-do them every few years. To this end there has to be a standard.
If we sit and watch Israel and the Arab countries slaughter it out, maybe
we lose oil and the full benefits of those cultures as they destroy each
other. If we try to separate them, are we participating in a religious
war, or are we simply trying to stop one?
Ohlander and Squires like D-machines. ARPA funded and BBN and Xerox for
many years to maintain the TENEX/InterLisp standard, which was the ARPA
`standard' for about a decade. I've heard that Squires is talking about a
validation suite that Symbolics would have to pass in march. I've heard he
thinks they're dragging their feet. I've heard that he said that if they
drag their feet any more, DARPA will no longer buy 3600's. If this is
true - and from my discussion with them this is all very plausible - I
would not say the Ohlander is anti-Xerox. Like me, he is frustrated with
their idiotic management decisions.
``The second group is funded in large part by DARPA.''
I don't think so. There may be hard core of InterLisp devotees, but to the
newer generation of AI hackers, the farm and gay Paris don't look much
different from each other. Many companies seem to be going with Common
Lisp - DEC, DG, SUN, Apollo, TI, HP (bizarre but true, Griss
notwithstanding), Prime (possibly), Sperry, Honeywell, etc. Business
reality doesn't give a shit about religious wars; academics do. If the
commercial world goes Common Lisp, Xerox had better follow. The question
is: Will the commercial world go? I think so.
-rpg-
∂02-Oct-84 1902 FAHLMAN@CMU-CS-C.ARPA Cannery Row Lisp
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 2 Oct 84 19:02:25 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Tue 2 Oct 84 22:01:04-EDT
Date: Tue, 2 Oct 1984 22:00 EDT
Message-ID: <FAHLMAN.12052354560.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Christopher Schmidt <SCHMIDT@SUMEX-AIM.ARPA>
Cc: rpg@SU-AI.ARPA, fahlman@CMU-CS-C.ARPA
Subject: Cannery Row Lisp
If it is really as bad as you say and your employers expect you to make
do with 1/4 of a personal machine a mile away -- any personal machine,
let alone one that you don't like -- then you are clearly working for
cretins and it's time to change jobs. Haven't they heard that Lisp
hackers are rare and that if they have one, his time is too valuable to
waste? I can't believe that it's really that bad, however.
To answer your question about a port, the question is which D-machine
you're talking about. To port our Spice Lisp code to the Dandelion with
the larger control store would be very easy, I think -- just a matter of
rewriting about 7K of Perq microcode for the new machine. (It would be
more compact on a Dandelion, I think.) For a good hacker, probably just
a couple of months once he gets rolling, plus an open-ended period of
tuning beyond that. With a few months spent on tuning, this system
would probably run considerably faster than on a Perq.
The only major problem would be that our Lisp is just a Lisp. It
depends on the underlying Accent operating system to provide virtual
memory support, I/O, screen management, network services, etc. You
would either have to (a) write Lisp code and a little microcode support
to provide these services, (b) use some other operating system -- the
Xerox Development Environment is an obvious candidate -- to provide the
same services and alter the Lisp code a bit to interface properly with
this different system, or (c) import the rest of our Spice system as
well. I think that any of these options would probably be easier than
trying to alter the existing Interlisp system to be a complete Common
Lisp, though you could get 90% compatibility without too much trouble.
If the system must run on old Dandelions that can't be upgraded to the
larger microstore, it would take a lot more work to make the port and
the resultwould be a slower system. A lot of stuff would have to be
moved from microcode to macrocode. Dolphins may have the same problem
-- how much microstore do they have and how dense is it?
If the idea is to run on any generic D-machine, I guess that would mean
generating some D-machine instruction set rather than moving the
microcode. This implementation would then be more like the
stock-hardware implementation we did for the Vax than like the Perq
implementation. I'd have to look at the instruction set to see how much
performance this would give away and how hard it would be. Probably
something like a man-year would be reasonable (two people, six months),
with again an open-ended period of tuning after that. If it's possible
to add a FEW additional instructions to the existing set, it might be
a fairly reasonable implementation.
Whatever the strategy, such an implementaiton effort would have our full
and enthusiastic support, as well as the use of our code. I'd love to
see a Common Lisp running on Dandelions -- it would help to solve
everyone's political problems and would probably be a nice
implementation to use.
I have some additional thoughts on the current political situation, but
I'll send them in a separate note, with copies to some of the DARPA
people.
-- Scott
∂03-Oct-84 1017 SCHMIDT@SUMEX-AIM.ARPA Re: Cannery Row Lisp
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 3 Oct 84 10:17:29 PDT
Date: Wed 3 Oct 84 10:17:45-PDT
From: Christopher Schmidt <SCHMIDT@SUMEX-AIM.ARPA>
Subject: Re: Cannery Row Lisp
To: Fahlman@CMU-CS-C.ARPA
cc: rpg@SU-AI.ARPA
In-Reply-To: Message from ""Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>" of Tue 2 Oct 84 19:03:30-PDT
Thanks for the counsel on the D machine port. The labor estimates
you give are very close to those I guesstimated.
I hope we can convince the Xerox people to do it right.
Only if they refuse to do anything would I consider trying a port
on my own, of course. In that case, I would try to make your code run
on top of the Interlisp-D instruction set; analagous to a stock hardware
port, as you say. If I got anywhere, I do believe they would be willing
to add a few new opcodes for the effort.
I'll wait and see how the latest talks go before proceeding any
further.
--Christopher
-------
∂03-Oct-84 1026 FAHLMAN@CMU-CS-C.ARPA Cannery Row Lisp
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 3 Oct 84 10:26:05 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Wed 3 Oct 84 13:26:19-EDT
Date: Wed, 3 Oct 1984 13:26 EDT
Message-ID: <FAHLMAN.12052523008.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Christopher Schmidt <SCHMIDT@SUMEX-AIM.ARPA>
Cc: rpg@SU-AI.ARPA
Subject: Cannery Row Lisp
In-reply-to: Msg of 3 Oct 1984 13:17-EDT from Christopher Schmidt <SCHMIDT at SUMEX-AIM.ARPA>
Do you know of any document that clearly describes the Interlisp-D
instruction set, at a level of detail sufficient for an implementation?
If such a thing exists, I could look at it and get a much clearer
estimate of how hard such a port would be. It might be that with a few
ucode extensions, this would work out rather well; it might also be that
their low-level support is totally unsuited for Common Lisp. A few
details going one way or the other is all that it would take to make a
big difference.
-- Scott
∂03-Oct-84 1617 SCHMIDT@SUMEX-AIM.ARPA Re: Cannery Row Lisp
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 3 Oct 84 16:17:10 PDT
Date: Wed 3 Oct 84 16:15:44-PDT
From: Christopher Schmidt <SCHMIDT@SUMEX-AIM.ARPA>
Subject: Re: Cannery Row Lisp
To: Fahlman@CMU-CS-C.ARPA
cc: rpg@SU-AI.ARPA
In-Reply-To: Message from ""Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>" of Wed 3 Oct 84 10:27:02-PDT
I don't have a document on the instruction set. Below, I
provide a list of the opcodes, for what it's worth. I also include a
sample which is the code for DRIBBLE, which is a function that copies
the output stream of the process to another stream as well.
If you have an old copy of the PARC publication "Papers on
Interlisp-D", there is a paper by Larry Masinter called "Local
Optimization in the Interlisp-D compiler" or some such. This paper
explains part of the instruction set as it stood in '80, I think.
Unfortunately, this paper is not in later editions and someone has
stolen my copy, or I'd send you one. You can probably get a copy from
Larry.
I imagine Beau Sheil or Larry Masinter might be able to provide
better documentation on the instruction set.
--Christopher
14←(DRIBBLE '{SUMEX}<SCHMIDT>OPCODES.TXT)
NIL
15←(PRINTOPCODES)
# name len-1 format stk effect UFN table entry
370 FLOATBLT 0 T -4 \FLOATBLT
371 FFTSTEP 0 T -1 \FFTSTEP
372-374 unused
0 -X- 0 ? ?
1 CAR 0 T 0 \CAR.UFN
2 CDR 0 T 0 \CDR.UFN
3 LISTP 0 T 0 LISTP
4 NTYPX 0 T 0 NTYPX
5 TYPEP 1 TYPEP 0
6 DTEST 2 ATOM 0 \DTESTFAIL
7 CDDR 0 T 0 CDDR
10 FN0 2 FN 1
11 FN1 2 FN 0
12 FN2 2 FN -1
13 FN3 2 FN -2
14 FN4 2 FN -3
15 FNX 3 FNX FNX
16 APPLYFN 0 T -1
17 CHECKAPPLY* 0 T 0 \CHECKAPPLY*
20 RETURN 0 T 0 \HARDRETURN
21 BIND 2 ? ?
22 UNBIND 0 ? ?
23 DUNBIND 0 ? ?
24 RPLPTR.N 1 T -1 \RPLPTR.UFN
25 GCREF 1 T 0 \HTFIND
26 was.htfind 0 T ?
27 GVAR← 2 ATOM 0 \SETGLOBALVAL.UFN
30 RPLACA 0 T -1 \RPLACA.UFN
31 RPLACD 0 T -1 \RPLACD.UFN
32 CONS 0 T -1 \CONS.UFN
33 GETP 0 T -1 GETPROP
34 FMEMB 0 T -1 FMEMB
35 GETHASH 0 T -1 GETHASH
36 PUTHASH 0 T -2 PUTHASH
37 CREATECELL 0 T 0 \CREATECELL
40 BIN 0 T 0 \BIN
41 BOUT 0 T -1 \BOUT
42 BITBLT 0 T -1 BitBltSUBR
43 LIST1 0 T 0 CONS
44 DOCOLLECT 0 T -1 DOCOLLECT
45 ENDCOLLECT 0 T -1 ENDCOLLECT
46 RPLCONS 0 T -1 \RPLCONS
47 unused
50 ELT 0 T -1 ELT
51 NTHCHC 0 T -1 NTHCHARCODE
52 SETA 0 T -2 SETA
53 RPLCHARCODE 0 T -2 RPLCHARCODE
54 EVAL 0 T 0 \EVAL
55 EVALV 0 T 0 \EVALV1
56 unused
57 STKSCAN 0 T 0 \STKSCAN
60- 72 unused
73 \MU.DRAWLINE 0 T -8 \DRAWLINE.UFN
74 STORE.N 1 T 0
75 COPY.N 1 T 1
76 RAID 0 T 0 RAID
77 \RETURN 0 T 0 \RETURN
100-106 IVAR 0 IVAR 1
107 IVARX 1 IVAR 1
110-116 PVAR 0 PVAR 1
117 PVARX 1 PVAR 1
120-126 FVAR 0 FVAR 1
127 FVARX 1 FVAR 1
130-136 PVAR← 0 PVAR 0
137 PVARX← 1 PVAR 0
140 GVAR 2 ATOM 1
141 ARG0 0 T 0 \ARG0
142 IVARX← 1 IVAR 0
143 FVARX← 1 FVAR 0
144 COPY 0 T 1
145 MYARGCOUNT 0 T 1 \MYARGCOUNT
146 MYALINK 0 T 1
147 ACONST 2 ATOM 1
150 'NIL 0 T 1
151 'T 0 T 1
152 '0 0 T 1
153 '1 0 T 1
154 SIC 1 SIC 1
155 SNIC 1 SNIC 1
156 SICX 2 SICX 1
157 GCONST 3 GCONST 1
160 ATOMNUMBER 2 ATOM 1
161 READFLAGS 0 T 0 \READFLAGS
162 READRP 0 T 0 \READRP
163 WRITEMAP 0 T -2 \WRITEMAP
164 READPRINTERPORT 0 T 1 NILL
165 WRITEPRINTERPORT 0 T 0 NILL
166 PILOTBITBLT 0 T -1 \PILOTBITBLT
167 RCLK 0 T 0 \RCLKSUBR
170 MISC1 1 T 0 \MISC1.UFN
171 MISC2 1 T -1 \MISC2.UFN
172 RECLAIMCELL 0 T 0 \GCRECLAIMCELL
173 GCSCAN1 0 T 0 \GCSCAN1
174 GCSCAN2 0 T 0 \GCSCAN2
175 SUBRCALL 2 ? ?
176 CONTEXTSWITCH 0 T 0 \CONTEXTSWITCH
177 AUDIO 0 T 0 NILL
200-217 JUMP 0 JUMP JUMP
220-237 FJUMP 0 JUMP CJUMP
240-257 TJUMP 0 JUMP CJUMP
260 JUMPX 1 JUMPX JUMP
261 JUMPXX 2 JUMPXX JUMP
262 FJUMPX 1 JUMPX CJUMP
263 TJUMPX 1 JUMPX CJUMP
264 NFJUMPX 1 JUMPX NCJUMP
265 NTJUMPX 1 JUMPX NCJUMP
266 jeq ? ? ?
267 jlistp ? ? ?
270-276 PVAR←↑ 0 PVAR -1
277 POP 0 T -1
300 was.getbase ? ? ?
301 was.getbaseptr ? ? ?
302 GETBASEBYTE 0 T -1 \GETBASEBYTE
303 was.scanbase ? ? ?
304 BLT 0 T -2 \BLT
305 was.putbase ? ? ?
306 was.putbaseptr ? ? ?
307 PUTBASEBYTE 0 T -2 \PUTBASEBYTE
310 GETBASE.N 1 T 0
311 GETBASEPTR.N 1 T 0
312 GETBITS.N.FD 2 T 0
313 unused
314 unused
315 PUTBASE.N 1 T -1 \PUTBASE.UFN
316 PUTBASEPTR.N 1 T -1 \PUTBASEPTR.UFN
317 PUTBITS.N.FD 2 T -1 \PUTBITS.UFN
320 ADDBASE 0 T -1 \ADDBASE
321 VAG2 0 T -1 \VAG2
322 HILOC 0 T 0
323 LOLOC 0 T 0
324 PLUS2 0 T -1 PLUS
325 DIFFERENCE 0 T -1 DIFFERENCE
326 TIMES2 0 T -1 TIMES
327 QUOTIENT 0 T -1 QUOTIENT
330 IPLUS2 0 T -1 \SLOWIPLUS2
331 IDIFFERENCE 0 T -1 \SLOWIDIFFERENCE
332 ITIMES2 0 T -1 \SLOWITIMES2
333 IQUOTIENT 0 T -1 \SLOWIQUOTIENT
334 IREMAINDER 0 T -1 IREMAINDER
335 IPLUS.N 1 T 0 \SLOWIPLUS2
336 IDIFFERENCE.N 1 T 0 \SLOWIDIFFERENCE
337 unused
340 LLSH1 0 T 0 \SLOWLLSH1
341 LLSH8 0 T 0 \SLOWLLSH8
342 LRSH1 0 T 0 \SLOWLRSH1
343 LRSH8 0 T 0 \SLOWLRSH8
344 LOGOR2 0 T -1 \SLOWLOGOR2
345 LOGAND2 0 T -1 \SLOWLOGAND2
346 LOGXOR2 0 T -1 \SLOWLOGXOR2
347 unused
350 FPLUS2 0 T -1 FPLUS2
351 FDIFFERENCE 0 T -1 FDIFFERENCE
352 FTIMES2 0 T -1 FTIMES2
353 FQUOTIENT 0 T -1 FQUOTIENT
354-357 unused
360 EQ 0 T -1
361 IGREATERP 0 T -1 \SLOWIGREATERP
362 FGREATERP 0 T -1 FGREATERP
363 GREATERP 0 T -1 GREATERP
364 unused
365 MAKENUMBER 0 T -1 \MAKENUMBER
366 BOXIPLUS 0 T -1 \BOXIPLUS
367 BOXIDIFFERENCE 0 T -1 \BOXIDIFFERENCE
370-374 unused
375 SWAP 0 T 0
376 NOP 0 T 0
377 UPCTRACE 0 T 0 NILL
NIL
16←(DRIBBLE]
18←(DRIBBLE '{SUMEX}<SCHMIDT>DRIBBLE.MAC)
NIL
19←(PRINTCODE 'DRIBBLE)
stkmin: 76 na: 3 pv: 2 startpc: 60 argtype: 0 framename: DRIBBLE ntsize: 4 nlocals: 3
0: 76
2: 3
4: 2
6: 60
10: 0
12: 5311
14: 4
16: 1411
name table:
20: 1200 30: 100002 PVAR 2: \INTERRUPTABLE
22: 4677 32: 140003 FVAR 3: \DRIBBLE.OFD
24: 4747 34: 140004 FVAR 4: TtyDisplayStream
26: 0 36: 0
Local args:
40: 5307 50: 2 IVAR 2: THAWEDFLG
42: 5310 52: 1 IVAR 1: APPENDFLG
44: 1321 54: 0 IVAR 0: FILE
46: 0 56: 0
----
60: 123 FVAR \DRIBBLE.OFD
61: 265 11 NTJUMPX-> 72
63: 151 'T
64: 11 12 313 FN1 RESTARTDRIBBLE
67: 264 3 NFJUMPX-> 72
71: 123 FVAR \DRIBBLE.OFD
72: 21 21 1 BIND [pvar0]; [pvar1]
75: 21 20 2 BIND ; \INTERRUPTABLE
100: 150 'NIL
101: 143 6 FVARX← \DRIBBLE.OFD
103: 277 POP
104: 124 FVAR TtyDisplayStream
105: 11 11 353 FN1 \REMOVEDRIBBLECHECK
110: 23 DUNBIND
111: 110 PVAR [pvar0]
112: 265 33 NTJUMPX-> 145
114: 100 IVAR FILE
115: 265 13 NTJUMPX-> 130
117: 110 PVAR [pvar0]
120: 144 COPY
121: 224 FJUMP-> 127
122: 311 4 GETBASEPTR.N
124: 265 3 NTJUMPX-> 127
126: 110 PVAR [pvar0]
127: 20 RETURN
130: 151 'T
131: 360 EQ
132: 263 365 TJUMPX-> 117
134: 100 IVAR FILE
135: 101 IVAR APPENDFLG
136: 262 37 FJUMPX-> 175
140: 147 3 323 ACONST APPEND
143: 260 35 JUMPX-> 200
145: 6 2 346 DTEST STREAM
150: 153 '1
151: 317 4 60 PUTBITS.N.FD
154: 277 POP
155: 110 PVAR [pvar0]
156: 6 2 346 DTEST STREAM
161: 153 '1
162: 317 4 100 PUTBITS.N.FD
165: 277 POP
166: 110 PVAR [pvar0]
167: 11 4 167 FN1 CLOSEF
172: 277 POP
173: 260 321 JUMPX-> 114
175: 147 2 326 ACONST OUTPUT
200: 150 'NIL
201: 144 COPY
202: 102 IVAR THAWEDFLG
203: 264 5 NFJUMPX-> 210
205: 147 12 314 ACONST THAWED
210: 15 5 4 166 FNX(5) OPENSTREAM
214: 131 PVAR← [pvar1]
215: 6 2 346 DTEST STREAM
220: 152 '0
221: 317 4 60 PUTBITS.N.FD
224: 277 POP
225: 111 PVAR [pvar1]
226: 6 2 346 DTEST STREAM
231: 152 '0
232: 317 4 100 PUTBITS.N.FD
235: 277 POP
236: 21 20 2 BIND ; \INTERRUPTABLE
241: 111 PVAR [pvar1]
242: 143 6 FVARX← \DRIBBLE.OFD
244: 277 POP
245: 124 FVAR TtyDisplayStream
246: 11 12 312 FN1 \ADDDRIBBLECHECK
251: 23 DUNBIND
252: 260 245 JUMPX-> 117
254: 0 -X-
NIL
20←(DRIBBLE)
-------
∂03-Oct-84 1637 FAHLMAN@CMU-CS-C.ARPA Cannery Row Lisp
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 3 Oct 84 16:36:57 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Wed 3 Oct 84 19:37:15-EDT
Date: Wed, 3 Oct 1984 19:37 EDT
Message-ID: <FAHLMAN.12052590531.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Christopher Schmidt <SCHMIDT@SUMEX-AIM.ARPA>
Cc: rpg@SU-AI.ARPA
Subject: Cannery Row Lisp
In-reply-to: Msg of 3 Oct 1984 19:15-EDT from Christopher Schmidt <SCHMIDT at SUMEX-AIM.ARPA>
Thanks, but I can't tell much from this, except perhaps by doing a lot
more work than I want to in order to decipher it. If we decide it's
worth pursuing this, and if Xerox is willing to help, I'll try to figure
out what can be done with this instruction set. I've never understood
how anyone could build a big system without carefully documenting such
an important internal interface, but I guess these quaint notions about
software engineering don't last too long out there in the real world.
BTW, if you want to look at the document for our Spice Lisp instruction
set, let me know and I'll mail you one.
-- Scott
∂02-Oct-84 1424 SCHMIDT@SUMEX-AIM.ARPA Re: More Cannery-row Lisp
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 2 Oct 84 14:22:49 PDT
Date: Tue 2 Oct 84 14:23:14-PDT
From: Christopher Schmidt <SCHMIDT@SUMEX-AIM.ARPA>
Subject: Re: More Cannery-row Lisp
To: RPG@SU-AI.ARPA
cc: fahlman@CMU-CS-C.ARPA
I find all of what you say in your last letter very encouraging.
I am especially encourged by the note about Ohio State. When I was
there in July they were quite discouraged by the DARPA policies as they had
been presented to Ohio State; and were (until your letter) one of the reasons
I held my dark perceptions of Ohlander and DARPA. I wonder why Tom Bylander
didn't say anything to me about this in Monterey? No matter. I'll take
your word for everything you say.
I was unaware that a subset meeting was actually going to happen.
The non-activity of the CL-subsets list made me think that subsets weren't
going anywhere.
Can I assume someone will let me know what happened at the meeting?
Thanks,
--Christopher
P.S. I am lazy in that I have no urge to implement DEdit in Common Lisp.
This laziness is based largely on the fact that I already have a working
DEdit available to me and I don't have to worry about comments at all.
I overexaggerated the comment syntax as a problem. My mistake.
-------
∂02-Oct-84 2213 FAHLMAN@CMU-CS-C.ARPA World peace
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 2 Oct 84 22:12:47 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Wed 3 Oct 84 01:13:03-EDT
Date: Wed, 3 Oct 1984 01:12 EDT
Message-ID: <FAHLMAN.12052389510.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: quinquevirate@SU-AI.ARPA, ohlander@USC-ISI.ARPA, squires@USC-ISI.ARPA,
fateman@UCB-VAX.ARPA, griss.hplabs@CSNET-RELAY.ARPA, shiel.pa@XEROX.ARPA
Cc: fahlman@CMU-CS-C.ARPA
Subject: World peace
[ Some of the above addresses are guesses. If anyone has better
addresses for these people, please forward this. Also, feel free to
pass this around to others who might be interested. ]
I've been thinking a bit about how best to make peace between the Common
Lisp people, DARPA, the manufacturers who are tied to other Lisps
(Interlisp, Franz, PSL, T, etc.), and the users who still prefer these
other Lisps. Some of what I have to say probably belongs on the
"subsets" mailing list, but since it's mostly political I thought I'd
send it to this collection of people first.
I think that the smart thing for DARPA to do right now is to support us
in making Common Lisp the best possible environment and to help us with
our standardization efforts, but *NOT* to dictate the choice of Common
Lisp to researchers who prefer some other Lisp. Heavy-handed tactics
here will be counter-productive. As the Common Lisp community grows, as
Common Lisp appears on new and exciting machines, and as the Common Lisp
environment improves over time, more and more users will see for
themselves the advantages of making the switch. But to the greatest
extent possible, we should leave researchers free to choose their own
tools. AI research is hard enough to do, and if researchers feel they
are being arbitrarily deprived of their favorite tools, their output and
morale will certainly suffer.
People doing AI and AI-like research are often developing prototype
programs, and it would be nice if all of these prototypes were written
in the same language. This would make it easier for researchers to
study and build upon other researchers' results. But we must weigh this
convenience against the desires of the researchers themselves. After
all, a research system will almost always have to be done over before it
is suitable for any heavy use, and the conversion of the system to a
standard language could be done at the time of the rewrite.
Most people overestimate the difficulty of converting an application
program from one Lisp to another. We at CMU have moved several large
systems from Interlisp to Maclisp and from Franz Lisp to Common Lisp,
and it's really not a big deal. The only requirement is that you have
some knowledge of both Lisp systems and a list of the differences to
look out for. With a little bit of DARPA-supported tool-building, this
sort of conversion could be made almost trivial. Of course, programs
that make extensive use of system facilities (the display, low-level
tense I/O,) are harder, but there are relatively few of these and even
here a bit of tool-building (e.g. a set of fake Interlisp window calls
on the Symbolics machine) would go a long way toward making such
conversions easy.
Of course, some projects will have the goal of delivering running,
usable software, and in such cases DARPA has a legitimate need to
specify the language in which this software is to run. For AI software,
that language will probably be Common Lisp. Let me suggest that in such
cases DARPA should require that the delivered software RUN IN
a vanilla Common Lisp implementation. No offical "compromise subset" is
needed. People who develop their code in Common Lisp can use the full
language; people who prefer to work in Interlisp or PSL can simply avoid
using such troublesome features as lexical closures or multiple values.
We could easily develop a short list of "style suggestions" for people
trying to straddle the fence and a simple mechanical post-processor to
do whatever low-level syntactic conversion is needed. The
post-processor might also flag any code that will not run in Common
Lisp and that cannot be mechanically converted.
The point is not to make the translation of arbitrary programs fully
automatic -- that's too hard to do in general -- but just to provide a
reasonable option for people who prefer to work in some other Lisp but
who must occasionally deliver a chunk of Common Lisp software to DARPA
or some other contractor. Such people are still at some disadvantage as
compared to users of native Common Lisp -- they cannot use the full
richness of the language -- but I see no reason to force everyone to use
a subset just because some people are straddling a fence, or to force
the PSL people to use the same Common Lisp subset as the Interlisp
people. As long as the researchers can use whatever system they like
and ALL the delivered code runs adequately in Common Lisp, everyone
should be happy.
Finally, there is the question of whether DARPA should continue to pay
for the purchase of machines that do not run (or plan to run) Common
Lisp when (a) DARPA belives that Common Lisp will be an almost-universal
standard sometime in the future, (b) DARPA wants to see such a standard
emerge, and (c) DARPA plans to require certain kinds of software to be
delivered in Common Lisp sometime in the future. I think that the
question really is who is best qualified to make such a decision, the
researcher or the sponsor. DARPA should certainly advise contractors of
its beliefs and preferences about the future of Lisp, but if an
established research organization finds such arguments unconvincing, I
think that a wise sponsor would yield to the wisdom of the people down
in the trenches. They are the ones who have to live with the decision,
after all.
This whole problem would go away, of course, if SOMEONE were to do a
good Common Lisp implementation for the Dandelion. As far as I know, it
is the only machine currently of interest to the AI research community
for which no Common Lisp is planned. I think that DARPA, Xerox, and the
existing Dandelion user community would all benefit from this move,
regardless of how many users actually switch from Interlisp to this
version of Common Lisp. Having such an implmentation available would
decouple the choice of machine from the choice of language. As soon as
there is a firm commitment to produce a Dandelion Common Lisp, people
can buy Dandelions secure in the knowledge that if they ever want to
move to Common Lisp they can do so without having to buy new hardware.
At that point, they are free to continue using Interlisp as long as they
feel it is better, without taking the risk of being left behind. At
present, many people who like Interlisp are afraid to buy Dandelions
because they are afraid that they MIGHT be trapped in in a stagnant pool
far from the mainstream.
Xerox would not have to provide that Common Lisp implementation itself,
but would have to cooperate a bit to make it happen. With Xerox's
cooperation, it would only take a man-year or two. DARPA might help to
fund such an implementation, in the interest of protecting several
million dollars worth of hardware owned by its contractors, or someone
like Lucid might do it as a purely commercial venture. With the
recently-announced hardware extensions, I think that a Dandelion could
run Common Lip rather well.
Well, those are my own views, as of today. Let's try to keep the
communication lines open. If we all try to work for the common good and
to keep the other person's problems in mind, I think that we can solve
these problems with minimal pain all around. If a silly religious war
breaks out, everyone loses.
-- Scott
∂03-Oct-84 1756 FAHLMAN@CMU-CS-C.ARPA Cannery Row Lisp
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 3 Oct 84 17:55:50 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Wed 3 Oct 84 20:56:05-EDT
Date: Wed, 3 Oct 1984 20:56 EDT
Message-ID: <FAHLMAN.12052604888.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Christopher Schmidt <SCHMIDT@SUMEX-AIM.ARPA>
Cc: rpg@SU-AI.ARPA
Subject: Cannery Row Lisp
In-reply-to: Msg of 3 Oct 1984 20:42-EDT from Christopher Schmidt <SCHMIDT at SUMEX-AIM.ARPA>
Our document should be in the mail tomorrow. We have a new document on
the way which includes some new register instructions Skef did -- yet
another 30% improvement -- but that version isn't printed up yet. The
old one should suffice for now.
As for asking Xerox for their internal documents now, I have no reason
to believe that they're in anything remotely resembling a conciliatory
mood. They're talking with us, at least, but seem less friendly than
any time in recent memory. Let's see how things develop. If they
refuse to cooperate on this deal at all, then we should think hard about
whether this is worth doing; it will certainly be twice as hard that
way.
-- Scott
∂03-Oct-84 2114 SQUIRES@USC-ISI.ARPA Re: World peace
Received: from USC-ISI.ARPA by SU-AI.ARPA with TCP; 3 Oct 84 21:14:28 PDT
Date: 4 Oct 1984 00:14-EDT
Sender: SQUIRES@USC-ISI.ARPA
Subject: Re: World peace
From: Stephen L. Squires <SQUIRES@USC-ISI.ARPA>
To: Fahlman@CMU-CS-C.ARPA
Cc: quinquevirate@SU-AI.ARPA, ohlander@USC-ISI.ARPA
Cc: squires@USC-ISI.ARPA, fateman@UCB-VAX.ARPA
Cc: griss.hplabs@CSNET-RELAY.ARPA, shiel.pa@XEROX.ARPA
Cc: kahn@USC-ISI.ARPA
Message-ID: <[USC-ISI.ARPA] 4-Oct-84 00:14:13.SQUIRES>
In-Reply-To: <FAHLMAN.12052389510.BABYL@CMU-CS-C.ARPA>
This is a *VERY* important issue because it involves the health
of the community at a critical time in its growth. I hope that
it was clear at the recent Common LISP meeting (or future of LISP
meeting if you perfer) that DARPA sees Common LISP as solving
what it preceives to be a significant problem in managing the
delivery of the new generation of technology that will be
produced by the Strategic Computing Program. DARPA needs to have
maximal particpation of the community and wants to make use of
the accumulated organic knowledge base. In general, we believe
some mild constraints will significantly increase the gain of the
technology system. However, at any point in time, I believe that
we should use only the minimal constraints to achieve the desired
effect to insure that we to not significantly adversely affect
the rate of progress of the community for a significant period of
time. Since change always requires a period of transition, we
must carefully manage the rate of change, identify the community
affected, and insure that each new stage provides benefit to the
desired community.
I am very sympathetic to the needs of the people in the trenches.
You may be interested to learn that I spent over ten years in
those trenches. I worked in a research environment with
extraordinary computing resources and had essentually my own
PDP10 and later DEC System 20, high resolution graphics including
color, advanced workstations, XEROX STARS, Dandilions, and
Symbolics 3600s. I used a variety of dialects of LISP including
INTERLISP, and a variety of related languages and their
environments including MDL and ECL. Warren T would have been
right a home. I spent almost all my time developing rapid
prototypes for a variety of problem domains and extending the
environments to improve my performance. My intention in making
these personal remarks is not to brag, but to make it clear that
I have a deep appreciation for the needs of the people that are
actually developing the new generation and the importance of
listening to them very carefully. I know how much it meant to me
to know that people were listening to my needs and how painful it
was when "others" imposed almost anything that did not make sence
at the time (the pain must be worth the gain and the interaction
must have a rapid reaction).
The point is, I very much want to hear what the community has to
say on this issue and make sure that the right thing happens from
both its point of view and DARPA's. I believe that I have some
experience which will help make me very sensitive to the issues.
Before, I say any more, I would like to hear more...
∂04-Oct-84 0817 FAHLMAN@CMU-CS-C.ARPA World peace
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 4 Oct 84 08:16:51 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Thu 4 Oct 84 11:16:58-EDT
Date: Thu, 4 Oct 1984 11:16 EDT
Message-ID: <FAHLMAN.12052761607.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: "Stephen L. Squires" <SQUIRES@USC-ISI.ARPA>
Cc: fateman@UCB-VAX.ARPA, griss.hplabs@CSNET-RELAY.ARPA, kahn@USC-ISI.ARPA,
ohlander@USC-ISI.ARPA, quinquevirate@SU-AI.ARPA, sheil.pa@XEROX.ARPA
Subject: World peace
In-reply-to: Msg of 4 Oct 1984 00:14-EDT from Stephen L. Squires <SQUIRES at USC-ISI.ARPA>
Steve,
I think this is a *VERY* important issue too. That's why I've spent
three rather intense years trying to make Common Lisp happen. My own
hope is that Common Lisp will continue to grow in such a way that it
becomes a standard that people embrace voluntarily, and that very few
"constraints" will be needed. This might take a little longer, but it
will be less disruptive during the period of transition and will leave
everyone feeling a lot better the day after. Carrots usually work
better than sticks when you want the donkey to keep pulling and don't
want to damage him. Everyone knows that the stick is out there, to be
used if all else fails.
In talking with people before and since the Monterey conference, I
think the big fear is that at some point in the too-near future DARPA
may lay down an inflexible blanket policy that would either require
people to write their code on a certified Common Lisp system, or would
prohibit them from buying equipment that does not support such a system.
A lot of people out there -- not just the people at Xerox -- are
frightened and incensed about this prospect. I'm sure it is DARPA's
intention to be flexible and reasonable, as always, but that sort of
thing gets lost in the rumor mill. One case in which someone feels that
he was unreasonably over-constrained and starts complaining about it can
throw everyone else into a lather.
Anyway, the set of positions I proposed in my previous note was intended
to be one way of setting up the minimum necessary constraints, and a way
that might go down a bit better than saying "we require all work to be
done Common Lisp, but will be reasonable in applying this requirement".
-- Scott
∂04-Oct-84 1911 SQUIRES@USC-ISI.ARPA Re: World peace
Received: from USC-ISI.ARPA by SU-AI.ARPA with TCP; 4 Oct 84 19:11:35 PDT
Date: 4 Oct 1984 22:11-EDT
Sender: SQUIRES@USC-ISI.ARPA
Subject: Re: World peace
From: Stephen L. Squires <SQUIRES@USC-ISI.ARPA>
To: Fahlman@CMU-CS-C.ARPA
Cc: SQUIRES@USC-ISI.ARPA, fateman@UCB-VAX.ARPA
Cc: griss.hplabs@CSNET-RELAY.ARPA, kahn@USC-ISI.ARPA
Cc: ohlander@USC-ISI.ARPA, quinquevirate@SU-AI.ARPA
Cc: sheil.pa@XEROX.ARPA
Message-ID: <[USC-ISI.ARPA] 4-Oct-84 22:11:09.SQUIRES>
In-Reply-To: <FAHLMAN.12052761607.BABYL@CMU-CS-C.ARPA>
I agree with the approach that you are advocating and strongly agree
that Common LISP should suceed on its merits. It is up to DARPA do
do what it can to support the process and "preserve world pease".
The time has come for the rumor mill to stop generating misleading
rumors for whatever purposes. What would be an effective way to
state the case and replace the rumors with constructive facts?
∂04-Oct-84 2017 FAHLMAN@CMU-CS-C.ARPA World peace
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 4 Oct 84 20:16:59 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Thu 4 Oct 84 23:16:47-EDT
Date: Thu, 4 Oct 1984 23:16 EDT
Message-ID: <FAHLMAN.12052892645.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: "Stephen L. Squires" <SQUIRES@USC-ISI.ARPA>
Cc: fateman@UCB-VAX.ARPA, griss.hplabs@CSNET-RELAY.ARPA, kahn@USC-ISI.ARPA,
ohlander@USC-ISI.ARPA, quinquevirate@SU-AI.ARPA, sheil.pa@XEROX.ARPA
Subject: World peace
In-reply-to: Msg of 4 Oct 1984 22:11-EDT from Stephen L. Squires <SQUIRES at USC-ISI.ARPA>
I'm glad you agree with the sort of approach I suggested. Once DARPA is
ready to propose a specific policy, the quickest way to replace the
rumors with facts would be to post something to COMMON-LISP @ SU-AI.
Not everyone concerned is on this mailing list, but that would certainly
get the word to enough people at once to kill off any rumors.
I would suggest, however, that any policy proposals be discussed and
debugged within this more limited forum first, not because we want to be
secretive, but just because it is impossible to discuss so tricky an
issue before a much larger group.
So far, I've heard nothing from the other recipients of this proposal
about whether they think it's a reasonable way to go. I've tried to
come up with a plan that minimizes the negative impact of the Common
Lisp standardization effort on the communities currently tied to other
Lisps, but only they can tell us whether I've succeeded. I may be blind
to some of their problems.
-- Scott
∂06-Oct-84 1931 SQUIRES@USC-ISI.ARPA Re: World peace
Received: from USC-ISI.ARPA by SU-AI.ARPA with TCP; 6 Oct 84 19:31:15 PDT
Date: 6 Oct 1984 22:30-EDT
Sender: SQUIRES@USC-ISI.ARPA
Subject: Re: World peace
From: Stephen L. Squires <SQUIRES@USC-ISI.ARPA>
To: Fahlman@CMU-CS-C.ARPA
Cc: SQUIRES@USC-ISI.ARPA, fateman@UCB-VAX.ARPA
Cc: griss.hplabs@CSNET-RELAY.ARPA, kahn@USC-ISI.ARPA
Cc: ohlander@USC-ISI.ARPA, quinquevirate@SU-AI.ARPA
Cc: sheil.pa@XEROX.ARPA
Message-ID: <[USC-ISI.ARPA] 6-Oct-84 22:30:34.SQUIRES>
In-Reply-To: <FAHLMAN.12052892645.BABYL@CMU-CS-C.ARPA>
To avoid starting another series of rumors, I think that it is
important to clarify what I believe we agree on since my
understanding is based upon a series of messages.
To "first order": DARPA should not "prematurely" standardize on
Common LISP, that DARPA should standardize on Common LISP for the
appropriate community of interest first (delivery of SC
products), and that standarization in other communities will
develop as development enviroments and advanced environment
components mature in Common LISP, and that DARPA should listen
carefully to the community with particular attention to those
actually producing LISP products and using those products so that
the transtition is managed effectively.
However, we have not yet discussed the specifics of the rate of
change that is needed and that can be tolerated.
I believe that we are at a critical point in the transition
process because of the potential to have the next generation of
LISP products including high performance machines using Common
LISP. DARPA needs to take a clearly defined strong position
which will encourage the next generation to support Common LISP
and to encourage the transition of the existing generation to
Common LISP while working hard to work with those using other
LISPs to facilitate the transtion. The notion of a Common LISP
subset with some additional systems support with perhaps a
strengthening of the package facility to allow integrating
packages using different extended Common LISPs may help this
process.
The time period for transition in the Strategic Computing product
community needs to be about two or three years. If it is any
longer then it may be too late to satisfy the needs of Strategic
Computing. This would mean that the products could be developed
in any effective development environment providing that the
product is in Common LISP (perhaps a subset) and that the
enviroment can be used to further develop (maintain) a product in
Common LISP (subset). It would take another few years for well
engineered development enviroments to emerge that are completely
in Common LISP.
I agree that it would be to discuss possible policy issues.
Since DARPA needs a solution to the multiple LISP problem it is
going to have to make some decision after listenting to all the
issues.
∂05-Oct-84 1555 GRISS%hp-hulk.csnet@csnet-relay.arpa Re: World peace
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 5 Oct 84 15:53:05 PDT
Received: from hplabs by csnet-relay.csnet id cb17713; 5 Oct 84 18:15 EDT
Received: by HP-VENUS id AA19112; Thu, 4 Oct 84 15:15:47 pdt
Message-Id: <8410042215.AA19112@HP-VENUS>
Date: Thu 4 Oct 84 15:16:47-PDT
From: Martin <GRISS%hplabs.csnet@csnet-relay.arpa>
Subject: Re: World peace
To: Fahlman%cmu-cs-c.arpa@csnet-relay.arpa,
quinquevirate%su-ai.arpa@csnet-relay.arpa,
ohlander%usc-isi.arpa@csnet-relay.arpa,
squires%usc-isi.arpa@csnet-relay.arpa,
fateman%ucb-vax.arpa@csnet-relay.arpa,
griss.hplabs%csnet-relay.arpa@csnet-relay.arpa,
shiel.pa%xerox.arpa@csnet-relay.arpa
Cc: fahlman%cmu-cs-c.arpa@csnet-relay.arpa, GRISS@hplabs.CSNET
In-Reply-To: Message from ""Scott E. Fahlman" <Fahlman@CMU-CS-C>" of Wed 3 Oct 84 00:03:13-PDT
Source-Info: From (or Sender) name not authenticated.
I have carefully read Scott's and Steve's remarks. As you may know, I
have been involved with the use and implementation of LISP
"interchange subsets" and "portable subsets" for some time.
Standard LISP (1969, 1979) was an attempt to produce a simple
community concensus LISP for use in importing code onto a variety of
different machines and existing LISPs. Standard LISP was primarily
used to support research in the area of computer algebra (between
groups in the US, UK, Europe and Japan); it also saw use to permit the
porting of CAI code and experimental LISP-based languages. Some people
expanded the definition and made it the basis of new LISP
implementations (such as UT-LISP, some microcomputer LISPs, a portable
BCPL based Cambridge LISP, and PSL, my own portable LISP). A number of
portable tools evolved (Portable compiler, etc) that have been
exchanged by the community.
While I agree with Scott that it is not totally impossible to convert
finished programs from one dialect to the other, we have found it
intolerable to exchange code under development between dialects. (In
the algebra community, we have been exchanging major components of
frequently during their development over a number of years). Thus I
believe it is important to consider the need for an "interchange
subset" which is rich enough to do much of ones programming, or at
least of the parts that one wishes to exchange. Many of us feel that
Common LISP as it stands is rather large, and gaining community
consensus on a subset would be easier, as perhaps a step in the
transition to use of "full" Common LISP.
As part of my work at HP (dealing with networks of dissimilar
machines, different development and execution environments, layered
implementations of LISPs, etc..), and because of my own interests in
"world peace" I have been exploring a "new subset" with the Standard
LISP and PSL communities. The goal is to see what concensus I can
obtain for a successor to Standard LISP (and PSL) that is a
significant subset of Common LISP. If the results seem reasonable, I
will share the revised proposal and comments with the CL-subset
working group, for possible broadening (narrowing?) and revision to
include a wider community. At least my efforts will perhaps "bring in"
a segment of the non-Common LISP community.
At HP and some universities, we are running a variant of PSL that has
significant CL compatibility, and are working on tools to aid in the
transition from PSL to (a subset of) Common LISP. As these tools and
the subset definition matures, with use and input from our SL/PSL
community, I will have a better idea, and a more concrete proposal, of
what subset will be accepatable.
Martin Griss
-------
∂08-Oct-84 2148 RPG Xerox
To: fahlman@CMU-CS-C.ARPA
CC: "#MONTER.NOT[COM,LSP]"@SU-AI.ARPA
Their plan is, I think, to mutate InterLisp to have this new subset as
one of its subsets. Then they plan to go to every customer they have already
and help them update their code. They won't deny having at
least 200 - 300 customers with a base of about 400 machines, and `as
a Fortune 100' company they cannot switch out from under them.
Sheil stated that he believed that AI was shakey enough in the marketplace,
that if Xerox rocked the boat, it might capsize. As an example of the
scenario he imagines, suppose some wide-eyed hacker just convinced
middle management to buy a Dandelion on the basis that he would
finish a tough project by day x. Then Xerox switches to Common Lisp,
causing this guy's schedule to slip by 6 months. That's it for AI
at that company.
From Xerox's point of view, if this argument holds waters, what they
plan to do (switch to a different underlying Lisp) is pretty radical
and interesting.
Perhaps they also think that if Xerox were to switch allegiances in mid-stream,
that might also rock the boat too much.
Sheil said they were willing to go the distance on a new language feature
(like lexical scoping) if it had a clear advantage, as lexical scoping
does. But in their evaluation function, the cost to them of going to
every customer and of rocking the AI boat figures in more than it
does to us academics.
On the other hand, maybe they're reacting with their glands and not their
neurons. I'm just not sure, yet, how to read the negotiations.
-rpg-
∂08-Oct-84 1300 FAHLMAN@CMU-CS-C.ARPA World peace and Xerox
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 8 Oct 84 12:59:50 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Mon 8 Oct 84 15:58:08-EDT
Date: Mon, 8 Oct 1984 15:57 EDT
Message-ID: <FAHLMAN.12053861341.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Dick Gabriel <RPG@SU-AI.ARPA>
Cc: fahlman@CMU-CS-C.ARPA
Subject: World peace and Xerox
In-reply-to: Msg of 8 Oct 1984 14:54-EDT from Dick Gabriel <RPG at SU-AI.ARPA>
Well, Xerox's unwillingness even to let someone else do a Common Lisp
on their machines is a clear signal: either they think that Interlisp
still might prevail (doubtful that they believe this), or they think
that by playing it tough they increase our willingness to cave in to
some of their demands (exactly the opposite is true with me), or they
have decided that their most profitable course is to wring whatever they
can out of the people who are, for now at least, trapped on Xerox
hardware. That last option is the likely one, and it will buy them one
or two more good years at the cost of making them outcasts in the AI
community from that point on. Too bad.
How much of this is settled and public -- if that is their position, I
sure wouldn't want anyone to buy any D machines on the assumption that
sooner or later Xerox will have to be reasonable.
Anyway, I think that most of what I suggested earlier still holds --
it's up to them to figure out how to make it easy for their users to
write code that will RUN IN a vanilla Common Lisp. We should help them
to figure that out, but there's no reason for us (or DARPA) to bless
their subset in any way. The easier they make it, the fewer of their
users are driven over to other systems prematurely. The only reason
that we might want to have an official subset was if there were a real
desirtsire for interchange -- code that would port both ways and run on
either system -- and I don't think there is.
I'd be interested in seeing this Lucid subset spec. I still think that
it's a very serious mistake for Lucid to go with a subset, excpet maybe
as a temporary expedient that is advertised as such.
-- Scott
∂09-Oct-84 0739 FAHLMAN@CMU-CS-C.ARPA Xerox
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 9 Oct 84 07:39:46 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Tue 9 Oct 84 10:37:35-EDT
Date: Tue, 9 Oct 1984 10:37 EDT
Message-ID: <FAHLMAN.12054065143.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Dick Gabriel <RPG@SU-AI.ARPA>
Cc: fahlman@CMU-CS-C.ARPA
Subject: Xerox
In-reply-to: Msg of 9 Oct 1984 00:48-EDT from Dick Gabriel <RPG at SU-AI.ARPA>
Well, this "boat rocking" argument is clearly horseshit. Nobody is
proposing that Xerox go to their customers and tell them "too bad, but
we've decided to flush Interlisp and you have to switch immediately to
Common Lisp". That would indeed capsize the boat and screw many people
badly. Even if Xerox were to say that they are going over to Common
Lisp soon, and that support and maintenance for Interlisp would be
severely curtailed right away, that would make some waves.
What I was proposing is something completely different: Xerox would
build (or allow someone to build) a Common Lisp environment for their
hardware. They would announce right now that this is going to happen,
allaying everyone's anxiety. Any shift of their support group and new
projects over to Common Lisp would occur only gradually, at Xerox's
discretion, but guaranteeing at least some level of Interlisp support
for, say, two years. Xerox could let the Common Lisp support come from
whoever builds that system, or could track their customers as they move
over, or could slightly take the lead by starting new projects in Common
Lisp. However they do this, they end up with an orderly transition and
fairly happy customers.
If they decide that there shall be no Common Lisp on the D machines,
that rocks the AI boat very severely. First of all, they are telling
the owners of the existing D machines "Tough luck if you want to join
the rest of the world. You bought our machines and now you have to
stick with Interlisp or totally replace all your hardware." If they are
worried about the poor guy who has to tell his boss about a six-month
slip due to a language changeover, they should be equally worried about
the guy who has to tell his boss that this million-dollar pile of
machines is now junk and has to be replaced if they don't want to become
an isolated backwater in the AI community. Also, they pretty much rule
out the option of buying D machines for anyone in the future, except
those very few shops that are pure Interlisp shops and are sure they
want to stay that way. A lot of people whose best interests and taste
tells them that they want to stick with Interlisp for awhile and maybe
change over to Common Lisp later will have to make the transition now or
risk being stuck with dead-end hardware. I don't think that their
compatibility subset is going to be seen by many people as an attractive
long-term option when real Common Lisp machines are being sold for $20K.
So I would claim that they make the transition even more abrupt and
traumatic for people by trying to prevent Common Lisp from appearing on
the Dandelion.
As you say, none of this is likely to get through to them in their
current mood. At least its a self-limiting problem: if they really are
ging to be this pig-headed, then the Xerox user community that we all
care so much about will not exist a year from now. But it will be a
painful year for some of them.
-- Scott
∂15-Oct-84 0752 OHLANDER@USC-ISI.ARPA Re: World peace
Received: from USC-ISI.ARPA by SU-AI.ARPA with TCP; 15 Oct 84 07:52:11 PDT
Date: 15 Oct 1984 10:51-EDT
Sender: OHLANDER@USC-ISI.ARPA
Subject: Re: World peace
From: OHLANDER@USC-ISI.ARPA
To: Fahlman@CMU-CS-C.ARPA
Cc: Steele@TL-20B.ARPA, RPG@SU-AI.ARPA, Squires@USC-ISI.ARPA
Message-ID: <[USC-ISI.ARPA]15-Oct-84 10:51:27.OHLANDER>
In-Reply-To: <FAHLMAN.12052389510.BABYL@CMU-CS-C.ARPA>
Scott,
I am happy to note your concern about the fate of the
various Lisp user subcommunities. I too very much want to avoid
religious wars. However, I think there might be some problems
with your premises. For one thing, you can be very sure that
there is no way to make everyone happy. The best that can happen
is for everyone to accept some compromise. Secondly, I think
that it is wistful thinking to suppose that Xerox will implement
Common Lisp without some considerable pressure to do so.
Thirdly, you talk about people protecting their investment. But
in a few years their investment will be much greater and it will
be much harder to change over, no matter how good Common Lisp is.
Remember, Interlisp already possesses much of the environment
that people would like but there are significant barriers to
Interlisp ever becoming a widespread standard.
While we don't want to start religious wars, I think the timing
is critical to instantiating Common Lisp as a standard. We don't
want to ram it down people's throats but we want to give clear
signals to people that Common Lisp will become the standard.
While DARPA won't mandate it for all research, I believe that we
will require delivery of code in Common Lisp for the Strategic
Project. Making this requirement is not simply a matter of
supporting Common Lisp as a standard, it is necessary to our
program. It is going to be hard enough to make things work
without aggravating the problems of software dialect
proliferation.
There are a number of vendors who are about ready to make
investments in Lisp Languages. If we exert some mild pressure
now, they will choose Common Lisp. If we wait and do nothing
there will be a number of them that choose other dialects. The
fact is that a number of these vendors are looking for guidance
and would like us to take some position. I believe that we would
be doing them and the whole community a disservice by not pushing
for Common Lisp.
Another factor to consider is that Common Lisp is the only
strongly supported Lisp dialect in the public domain. It is the
only Lisp dialect that offers the potential for standardization.
Another issue is that Lisp machines are becoming big time. If
you check the recent issue of Business Week, you will find an
article discussing that issue. It describes the percentage of
sales that are now going to industry and notes that only 25% are
going to laboratories. Projections show that the researcher
market share will be be much less than that in the near future.
That means that we may all lose our leverage in influencing a
standard as time goes on. I feel that this issue constitutes an
overwhelming reason for doing all that we can to promote Common
Lisp as a standard while we still can.
As I said earlier, I support your concerns and welcome your
sensitivity to the many issues surrounding the Common Lisp
phenomenon. Thus, we must walk the fine line of strongly
supporting Common Lisp while not totally alienating any important
segment of the community. I think the way to do this is to come
out with a public requirement for Common Lisp in the Strategic
Computing program. There will be no requirement for any
particular architectures; only that the code must be delivered in
Common Lisp in two years time. The Common Lisp delivered may
very possibly be a vanilla form, as you suggested. That is why I
supported a subset committee to look into this issue. You made
the point that a subset did not need to be defined in order to do
this, but I feel that it wuold be highly desireable for the
committee to actually specify an agreed upon subset. This will
accomplish at least two objectives. It will assure the involved
vendors that their concerns are being addressed and it will also
encourage places like Xerox to take the first step towards Common
Lisp compatibility. It might also prevent wide proliferation of
subsets.
In summary, let me say that I support your concerns and want to
prevent religious wars. However, I think we can do that while
judiciously putting more and more emphasis on Common Lisp as a
standard. I think the first step should be some stand on
requirements for the Strategic Computing program which requires
code delivered in Common Lisp and permits every vendor to
participate simply by making some accomodation to Common Lisp,
which should not be onerous. In addition, progress will be made
in defining aa subset of Common Lisp will be permitted.
Ron
∂15-Oct-84 1019 FAHLMAN@CMU-CS-C.ARPA World peace
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 15 Oct 84 10:19:22 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Mon 15 Oct 84 13:18:23-EDT
Date: Mon, 15 Oct 1984 13:18 EDT
Message-ID: <FAHLMAN.12055667271.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: OHLANDER@USC-ISI.ARPA
Cc: RPG@SU-AI.ARPA, Squires@USC-ISI.ARPA, Steele@TL-20B.ARPA,
fahlman@CMU-CS-C.ARPA
Subject: World peace
In-reply-to: Msg of 15 Oct 1984 10:51-EDT from OHLANDER at USC-ISI.ARPA
Ron,
You make several points in your note. Let me respond to them
separately:
1. I agree that DARPA can and should use its influence to get users and
manufacturers to switch to Common Lisp. That influence is already being
felt, and the stampede to Common Lisp is well underway now. It doesn't
take much, given that everyone was milling around in a state of total
confusion, just waiting for a sign as to which way the world was going
to go. A steady level of pressure from DARPA, with no confusing
reverses, will keep things moving very nicely, I think. Acceptance of
Common Lisp as a DOD language, and the appearance of Common Lisp on some
additional machines (Vax running Unix, 68000-based machines, IBM 370...)
will finish the job.
My point was just that a little pressure goes a long way, and that DARPA
can get the job done while stopping well short of actual coercion,
except for certain deliverables. My rule of thumb on when is a good
time to stop is a variation on the Golden Rule: what actions by DARPA
would infuriate me if it were Interlisp that was becoming the standard
and not Common Lisp, and what actions would I have to accept as
reasonable, even though I don't like them?
I think that we're pretty close to agreement on how much persuasion is
useful, but the rumor mill has been at work and large parts of the
Interlisp user community seem to expect Federal troops to arrive any day
and delete all copies of Interlisp from their machines. I was just
suggesting that a bit of reassurance would help to calm these people
down, without diluting the clear message that Common Lisp is going to
win in the end.
2. On the question of Xerox, I certainly don't expect them to end up
happy. The question is where they go from here. The best ending, from
our point of view, would be for them to continue their support for
Interlisp for awhile and either develop a Common Lisp for their
hardware or at least cooperate with someone else who wants to do this.
(It would also be nice if they admitted that Common Lisp was going to
win, but let's be realistic here.) If they intend to interfere with the
development of a Common Lisp on their machines, the best move if to get
them to go public with this stand -- that puts the whole world on notice
that if they buy any further Xerox hardware, they are cutting themselves
off from the mainstream according to DARPA and all the rest of the
manufacturers. The worst case is to let them go on without a Common
Lisp, but making noises about how some sort of compromise is in the
works -- they could sell a lot more machines before the truth catches up
to them. A clear proposal that someone be funded to do Common Lisp for
the Dandelion would force their hand on this issue.
3. Even if Xerox decides to oppose us, we must be careful not to make
life harder than necessary for the people who are stuck with their
machines. Some help to them in salvaging what they can would be
appropriate.
4. By "vanilla" Common Lisp, I mean what's in the manual, not a subset.
I still think that this official subset business is a very bad idea.
Certainly you don't want to prevent people who have a full Common Lisp
from using the full language, just because some losers are trying to
straddle the fence. And you don't want to make the fence too
comfortable. I think that requiring the delivered code to RUN IN Common
Lisp, using whatever features of that language may be convenient, is the
right move. I can tell people how to code in a style that doesn't care
whether variable binding is lexical or dynamic, but I have no idea how
to turn that advice into a subset specification.
-- Scott
∂16-Oct-84 0508 OHLANDER@USC-ISI.ARPA Re: World peace
Received: from USC-ISI.ARPA by SU-AI.ARPA with TCP; 16 Oct 84 05:07:52 PDT
Date: 16 Oct 1984 08:07-EDT
Sender: OHLANDER@USC-ISI.ARPA
Subject: Re: World peace
From: OHLANDER@USC-ISI.ARPA
To: Fahlman@CMU-CS-C.ARPA
Cc: RPG@SU-AI.ARPA, Squires@USC-ISI.ARPA
Cc: Steele@TL-20B.ARPA
Message-ID: <[USC-ISI.ARPA]16-Oct-84 08:07:56.OHLANDER>
In-Reply-To: <FAHLMAN.12055667271.BABYL@CMU-CS-C.ARPA>
Scott,
I agree that the key to success is using judicial pressure
without getting heavy-handed about it so as to arouse people's
animosities and defense mechanisms. We hope to do this by
issuing very few official statements while making matters clear
in private discussions with the principles involved. At the same
time, we do have to accomodate, at least in the near term, places
like Xerox without sacrificing our long term goals.
In regard to Xerox's paranoia, I can assure you that the cause
did not originate from here. I think it's a natural outgrowth of
the emphasis being placed on Common Lisp and some feedback from
users in the community that certain vendors were saying that
Interlisp-base systems were no longer approved by DARPA. I hope
we have this issue straightened out. However, I think it is
still invevitable that Common Lisp will come to dominate and that
Xerox is beginning to realize this. I think that they will face
up to this and begin to make some accomodation in the near term.
They know that they have to do something within two years. I
believe that we will have to nurture them for a time though.
You bring up some telling points in regard to a subset. I think
that all of us will have to consider this in some detail at a
future time. I take it that your idea is that subsets are
inevitable but let us not officially bless anyone of them.
Ron
∂16-Oct-84 0853 FAHLMAN@CMU-CS-C.ARPA World peace
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 16 Oct 84 08:53:19 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Tue 16 Oct 84 11:51:43-EDT
Date: Tue, 16 Oct 1984 11:51 EDT
Message-ID: <FAHLMAN.12055913628.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: OHLANDER@USC-ISI.ARPA
Cc: RPG@SU-AI.ARPA, Squires@USC-ISI.ARPA, Steele@TL-20B.ARPA,
fahlman@CMU-CS-C.ARPA
Subject: World peace
In-reply-to: Msg of 16 Oct 1984 08:07-EDT from OHLANDER at USC-ISI.ARPA
Ron,
I hope you meant "judicious pressure" and not "judicial pressure". The
latter is what we're trying to avoid.
I think we are now in full agreement on this.
I was thinking not only of Xerox's paranoia, but also some paranoia from
people at Stanford's heuristic programming project, and at some
companies that have bought Xerox equipment in the last couple of years.
Many of these people like Interlisp a lot, and all of them are afraid of
having their machines turn into pumpkins. RPG has some mail from people
at HPP and Teknowledge that illustrates this pretty well.
As for the subset issue, my point is that there will indeed be
restricted styles of programming (not really subsets, but programming in
such a way as to hide the differences between two Lisps) that will make
it possible for someone using an uncommon Lisp to port his code easily
to Common Lisp. I speak from experience on this: for over a year we ran
our compiler both in Maclisp and in Perq Common Lisp, before burning our
bridges and going over to Common Lisp completely. But it is harmful to
try to codify this "subset" for the following reasons:
1. While the restricted style is easy enough to get the hang of, it is
very hard -- maybe impossible -- to describe it formally as a subset.
Such a formalization effort would probably succeed only by throwing out
more than is necessary, thereby making the restricted language harder to
use than it has to be.
2. The problem is made still harder if Interlisp, Franz, and PSL (and
maybe even T) people have to live in the same subset. Each of these
languages has a certain amount in common with Common Lisp, but the
mutual intersection has to be close to zero. In fact Franz and PSL will
have to make many fewer compromises than Interlisp or T, so why saddle
them with the added restrictions? They're the ones who are being
reasonable about all this and trying to find ways to cope.
3. These "restricted styles" will evolve over time. As certain
compatibility packages get written (a package system for PSL, for
instance), some of the older restricitons drop away.
4. I think that it is psychologically very attractive to drop the
problem on the various user communities. We should say "here's a
problem, solve it as best you can (with whatever help we can provide)"
rather than "here's the best solution our committee has come up with,
and now you have to use it".
5. When you have to make your code run in Common Lisp by adopting a
restricted coding style, this situation is inherently unstable. Every
day it is made clear to you that you would rather be using The Real
Thing, as you think about how to make your code portable. This exerts a
gentle but constant pressure to convert to real Common Lisp as soon as
possible. An official subset might live forever, even if it is ghastly
-- people will learn to cope and will polish it up to the point where
they can just barely tolerate it.
The comments above only apply to the problem of subsets to allow
development of Common Lisp code on uncommon Lisp systems. None of this
says anything about official subsets for tiny machines or for getting
Lisp applications into nosecones. I'm not in favor of those either, but
the arguments are different.
-- Scott
∂16-Oct-84 1207 OHLANDER@USC-ISI.ARPA Re: World peace
Received: from USC-ISI.ARPA by SU-AI.ARPA with TCP; 16 Oct 84 12:06:53 PDT
Date: 16 Oct 1984 15:06-EDT
Sender: OHLANDER@USC-ISI.ARPA
Subject: Re: World peace
From: OHLANDER@USC-ISI.ARPA
To: Fahlman@CMU-CS-C.ARPA
Cc: RPG@SU-AI.ARPA, Squires@USC-ISI.ARPA
Cc: Steele@TL-20B.ARPA
Message-ID: <[USC-ISI.ARPA]16-Oct-84 15:06:28.OHLANDER>
In-Reply-To: <FAHLMAN.12055913628.BABYL@CMU-CS-C.ARPA>
Scott,
I definitely meant judicious pressure.
In regards to subsets, you make some very relevant points and it
is something that all of us will have to think about and talk about. We
do have a committee looking into this issue and we will have to give due
consideration to what they come up with. In the meantime, the approach that
you suggest may be the one to follow, but how do we identify what needs to
be done to the various researchers who may be using Xerox machines?
Ron
∂16-Oct-84 1826 FAHLMAN@CMU-CS-C.ARPA World peace
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 16 Oct 84 18:26:08 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Tue 16 Oct 84 21:24:23-EDT
Date: Tue, 16 Oct 1984 21:24 EDT
Message-ID: <FAHLMAN.12056017894.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: OHLANDER@USC-ISI.ARPA
Cc: RPG@SU-AI.ARPA, Squires@USC-ISI.ARPA, Steele@TL-20B.ARPA
Subject: World peace
Ron,
I'm not sure what you mean by "how do we identify what needs to
be done to the various researchers who may be using Xerox machines?"
If you're asking what the guidelines are for writing Interlisp code that
will also run in Common Lisp, I can't help too much there. I don't know
Interlisp well enough. I can tell Maclisp or Franzlisp users what most
of the tricks are for straddling that particular fence.
My point, however, was that "we" don't need to solve that problem. Just
require that the delivered code run in some standard Common Lisp, and
let the Interlisp people figure out how this is done. We should be
friendly and helpful, but it's their problem. Each site doing this will
need a VAX or some other Common Lisp machine around so that they can
check whether they're succeeding. If it turns out to be too hard, then
maybe they'll switch.
-- Scott
∂17-Oct-84 0508 OHLANDER@USC-ISI.ARPA Re: World peace
Received: from USC-ISI.ARPA by SU-AI.ARPA with TCP; 17 Oct 84 05:08:01 PDT
Date: 17 Oct 1984 08:08-EDT
Sender: OHLANDER@USC-ISI.ARPA
Subject: Re: World peace
From: OHLANDER@USC-ISI.ARPA
To: Fahlman@CMU-CS-C.ARPA
Cc: RPG@SU-AI.ARPA, Squires@USC-ISI.ARPA
Cc: Steele@TL-20B.ARPA
Message-ID: <[USC-ISI.ARPA]17-Oct-84 08:08:05.OHLANDER>
In-Reply-To: <FAHLMAN.12056017894.BABYL@CMU-CS-C.ARPA>
Scott,
I wasn't asking you to provide a specific answer to the question
of dealing with Xerox machine users; it was a rhetorical question. The
point is, that if you tell someone to produce something that runs
in some standard "Common Lisp", you have to identify what that standard Lisp
contains, i.e., what must be included and what can be left
out. That gets us back to the issue of a subset.
Ron
∂17-Oct-84 0736 FAHLMAN@CMU-CS-C.ARPA World peace
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 17 Oct 84 07:36:03 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Wed 17 Oct 84 10:34:35-EDT
Date: Wed, 17 Oct 1984 10:34 EDT
Message-ID: <FAHLMAN.12056161764.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: OHLANDER@USC-ISI.ARPA
Cc: RPG@SU-AI.ARPA, Squires@USC-ISI.ARPA, Steele@TL-20B.ARPA
Subject: World peace
In-reply-to: Msg of 17 Oct 1984 08:08-EDT from OHLANDER at USC-ISI.ARPA
Ron,
Ah, that's why I misunderstood you. It seemed perfectly obvious to me
that when we say that something must "run in Common Lisp", we mean a
full Common Lisp, according to the book, and not a subset. It's fair to
use anything in the book. Of course, if the delivered code runs in any
ture subset of Common Lisp, it will run in a full Common Lisp as well.
So we're setting the least restrictive requirement on the code to be
delivered, while still assuring that all the delivered code, however
developed, can be run together on any machine with a full Common Lisp
implementation. If people choose to work within a subset, we don't have
to notice that -- I work within a subset as well, since I've never used
hyperbolic arctan and never plan to, but that doesn't bother anyone.
There are several full implementations available now on which code can
be tested: Vax/VMS, Perq, and DG, at least, and maybe LMI/TI if you
believe Greenblatt. There will soon be more. There are
some bugs in each of these now, but but no major omissions. (Well,
that's not quite true. All of these, I think, lack transcendental
operations on complex numbers, but that's only because we didn't notice
that Guy had made these non-optional in the published manual. He has
promised to produce some portable code to rectify this in the near
future.) Once the validation suite exists, we can get rid of any
residual small discrepancies among these implementations.
-- Scott
∂17-Oct-84 1032 OHLANDER@USC-ISI.ARPA Re: World peace
Received: from USC-ISI.ARPA by SU-AI.ARPA with TCP; 17 Oct 84 10:31:33 PDT
Date: 17 Oct 1984 11:08-EDT
Sender: OHLANDER@USC-ISI.ARPA
Subject: Re: World peace
From: OHLANDER@USC-ISI.ARPA
To: Fahlman@CMU-CS-C.ARPA
Cc: RPG@SU-AI.ARPA, Squires@USC-ISI.ARPA
Cc: Steele@TL-20B.ARPA
Message-ID: <[USC-ISI.ARPA]17-Oct-84 11:08:51.OHLANDER>
In-Reply-To: <FAHLMAN.12056161764.BABYL@CMU-CS-C.ARPA>
Scott,
Your position may be the best one. I'll have to think about
it and perhaps try it out on a few research groups to see what their reactions
are.
Ron
∂01-Dec-85 1756 Moon@SCRC-STONY-BROOK.ARPA More on the CL meeting
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 1 Dec 85 17:56:22 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 364899; Sun 1-Dec-85 20:53:51-EST
Date: Sun, 1 Dec 85 20:52 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: More on the CL meeting
To: Dick Gabriel <RPG@SU-AI.ARPA>
cc: quinquevirate@SU-AI.ARPA
In-Reply-To: The message of 30 Nov 85 15:57-EST from Dick Gabriel <RPG@SU-AI.ARPA>
Message-ID: <851201205239.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 30 Nov 85 1257 PST
From: Dick Gabriel <RPG@SU-AI.ARPA>
Would you folks be interested in a caucus before the meeting to talk
about what you think will go on? We can caucus via this medium, if you
like.
I'm busy but willing to listen to mail. I have not planned to participate in
the charter discussion at all.
....One phenomenon I'd like to point out to you as existing, but about which you
might not be aware, is that a large fraction of the programming-related
world that knows of Common Lisp, believes that there is a Common Lisp Group
that makes decisions and holds a standard somewhere. People are constantly
calling me and asking when the Common Lisp Group will decide this, that, or
the other thing. People tend to identify that group with us. Perhaps it's
time for us to demonstrate a little more leadership than we have in the past.
Does this mean that a fourth proposal should be put on the table, that anything
to which the five people on the title page of the manual agree among themselves
is the law and everyone else has to accept it?
moon/su
Does this mean ...
No, that is not what it means. On reading my remark I still believe it is as
clear as it seemed to me when I wrote it. Perhaps you ought to read it once
more, and, if it still seems to make as little sense to you as your remark
implies, I'd be happy to restate my comment in simpler terms. I suggest
you start by clarifying the word `leadership' in your mind.
Please note I do you the courtesy of replying privately; I am capable - and
even fond - of trading terse, wry comments in public, but in this case
I choose to not do so.
-rpg-
∂02-Dec-85 0828 DLW@SCRC-STONY-BROOK.ARPA More on the CL meeting
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 2 Dec 85 08:28:43 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 365216; Mon 2-Dec-85 11:23:12-EST
Date: Mon, 2 Dec 85 11:29 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: More on the CL meeting
To: Moon@SCRC-STONY-BROOK.ARPA
cc: quinquevirate@SU-AI.ARPA
In-Reply-To: <851201205239.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <851202112950.6.DLW@CHICOPEE.SCRC.Symbolics.COM>
Date: Sun, 1 Dec 85 20:52 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Does this mean that a fourth proposal should be put on the table, that anything
to which the five people on the title page of the manual agree among themselves
is the law and everyone else has to accept it?
I didn't get the impression that RPG was suggesting anything quite that
extreme. I, too, am aware that lots of people assume that there is a
"Common Lisp committee" out there somewhere, and that things are under
some kind of control. Right now, of course, that's not true; we don't
even have a forum for resolving ambiguities in the manual.
Big meetings such as the upcoming one can go on for a long time and not
produce any results, and if that happens at this meeting, not only will
we all feel like we wasted our time, but we will probably give up on
ever trying to have such a meeting again, because we'll be convinced
that it's hopeless. So it's important that this meeting get something
done, and give us all the feeling that progress is being made. The
question is how to help assure that the meeting really is effective.
My interpretation of what RPG was suggesting is that one way to help
make sure something happens is for us to show some leadership. We hope
that if we can form a core group (a) with a more or less consistent
opinion, and (b) with our implied prestige, then this might form a seed
around which other opinions could crystalize. If it turns out that a
lot of people are opposed to what the five of us might feel, then of
course we don't take any special kind of precedence. What we're trying
to prevent is a situation in which there are several alternatives, some
of which are better than doing nothing at all, but nothing at all gets
done because there's no way to build a concensus. At least that's my
interpretation.
dlw/su
Moon's Comments
Dan,
Yes, that is what I meant. I became somewhat pissed at Moon for his
comment and sent him what I suppose he took as a nasty reply. If I
were him I would not respond to my comment to him, so I believe
the matter should be dropped, except insofar as progress has to be
made on the front of consolidating the Common Lisp people.
Perhaps a fact not generally known, but one which would lead people to
suspect my motives, is that DARPA asked me to organize this meeting.
That is, Steve Squires did, and he was a little peeved that it couldn't
have happened earlier in the fall.
-rpg-